So you’ve decided to migrate to SCAYLE? Even though replatforming is a major undertaking that requires an extensive evaluation process. It is precisely this process, however, that SCAYLE has optimized so that together, step-by-step, we can complete even the most complex migration projects in just a few months. Let’s take a look at the main steps and major decisions along the way, so you know exactly what to expect.
Planning & Scoping
The first step in every replatforming project is extensive planning. Together, we need to understand the specifics of your individual use case and define the requirements for your new and improved shop system. Once the list of requirements is complete, we will go through them and assign priorities to each item. The next step is to define roles and responsibilities, so your and SCAYLE’s teams can work efficiently.
Defining Your Target Architecture
After planning and scoping, we will define a blueprint for the new overall system according to your goals and business structure and then break it down into the different segments. Now it’s time to rethink your existing structure and make improvements where necessary to eliminate problems that have always bothered you. Monolithic systems are struggling to meet growing demands. These systems are often too cumbersome and not flexible enough to keep up with fast-changing market standards. You should keep this in mind when migrating to a modern system. “Oftentimes, customers come to us with an IT architecture that has grown and developed over a long time. That structure might be unnecessarily complicated and stand in the way of future development”, explains Dennis Poteski, Senior Solution Architect at SCAYLE.
Is your shop system holding you back?
Customer expectations change constantly – especially in fast-paced B2C verticals. If your online shop is still running on a needlessly complex system, it will be near impossible to quickly and flexibly adapt your customer experiences.
Want to learn more about how the right IT structure can support your business? Read our white paper on design patterns in IT architecture.
Shop Structure, Checkout, Frontend
Defining the target architecture includes three major components: shop structure, checkout, and frontend. The shop structure can either stay as it is, or be redesigned – your choice. If your existing shop structure is well-thought-out and aligned with your business’s needs, there is no need to change a running system. But if you suffer from complicated processes, streamlining your shop structure might be the better move.
SCAYLE comes with a white-label checkout. You’ll benefit from a reliable solution that is very easy to adapt and integrate. The boilerplate approach allows for a quick setup, higher conversions, and quick adaptation to cater to your target customers, use cases, or country preferences. We have dedicated teams continuously working to improve our capabilities and make them suited to current and future customer needs.
There are three ways of connecting a frontend to SCAYLE’s backend: You can build your own, use a frontend as a service solution, or utilize our Storefront Core, our white-label front-end boilerplate to quickly start your unique frontends. Which solution is best suited for your business depends on your in-house developer resources and front-end requirements.
Deep Dive: What to do when your databases don’t scale?
Let’s dive into one of the typical decisions to make when deciding on your new shop structure: How to structure your databases. Imagine the following situation: You get more customers, more orders, and more deliveries. What sounds like a growth-oriented business strategist’s dream, might quickly become a developer’s nightmare: At some point, the database used to store all of that information won’t be able to handle the workload anymore, resulting in slow page speed or even downtime. So, how can we solve this specific problem?
Dennis explains: “There are two main ways of structuring databases: sharding and partitioning. While both reduce the data stored in a single database by dividing it into smaller sections, they do so in different ways. Which one you choose can depend on the kind of data you need to process.” Do you need to store customer data? Then sharding, the parallel use of several databases, might be the best choice for you. This process divides data into sections, for example, all customers whose last name begins with A-M, and customers whose last name starts with N-Z. This reduces the size of individual databases, making them faster to respond.
If you need to store large amounts of data but mainly use part of it, partitioning might be better suited to your use case. For example, you’re required to store all order data for past and current orders, but, as established, a single database can’t handle it all. In this case, partitioning might be better suited: Partitioning refers to the primary use of one database and the secondary use of others only when required. In our example, you could store all data accessed regularly, like everything concerning recent orders, in one database. All the information on older orders can be stored in a secondary database that is only accessed when needed.
All key decisions of defining your target architecture need to be continuously aligned with your individual business goals. Your business’s IT systems must serve as a foundation that allows your business to reach its goals and targets. “The kind of IT structure best suited to your business depends on your individual use case. The right decision will make your life easier in the long run”, says Dennis. But don’t worry: Our experts will support you and your team every step of the way.
Quality Assurance: Data, Training, and Testing
As soon as the shop structure is set up, it is time to ensure that everything runs smoothly and will continue to do so in the future. We will export and cleanse all data and map it to the new structure. Once the quality of data is ensured, we will start importing it into the new system.
Towards the end of the project, we will enter a phase of extensive end-to-end testing. In this phase, we test the core processes along the complete process route and across all systems involved. A big part of quality assurance is the training of all stakeholders: We will train everyone who needs to interact with SCAYLE’s user panel. In addition to the training, our comprehensive Resource Center provides all the information you need when using SCAYLE.
Final Data Migration & Go-Live
Finally, once the architecture is in place, all relevant interfaces are connected, and all data can be exchanged between the systems, the final data migration can take place. This involves customer and order data. Subsequently, after the data migration, comes the go-live phase, the actual switch to SCAYLE. We will plan every detail of the go-live and define comprehensive playbooks for roll-out and roll-back scenarios.
Once these final steps are complete, there is only one thing left to do: Celebrate your successful go-live. We will continue to closely monitor your shop’s performance and keep an eye out for any bugs, so that you can lean back and toast to your new shop.
A Shop System to Fit Your Needs
Replatforming an online business is an enormous undertaking. It takes time and effort to successfully complete all steps. But the end result is worth it: a streamlined shop architecture running reliably no matter how high traffic peaks might be, combined with a modern and inspiring user experience for your customers.
At the end of the day, there is no single blueprint for a replatforming project. Just like every use case has its differences and specificities, every replatforming process looks a little different. Your replatforming plan will be adapted to your specific needs. But we won’t leave you to fend for yourself – our business analysts and solution architects will be with you every step of the way.
Ready to start planning? Get in contact with our SCAYLE specialists.
Are you currently using Salesforce Commerce Cloud and thinking about the switch? Read our guide on replatforming from Salesforce Commerce Cloud to SCAYLE.