In short: Replatforming means moving your webshop to a new e-commerce platform. It is the riskiest release you will do, because the platform, the data and every connection change at once. Test the whole chain, not just the new site: migrated data, integrations, checkout and payment, and the switch itself.

Most replatforming guides spend pages on choosing a platform and a few lines on testing. That is the wrong way round once the decision is made. A new platform can work fine in a demo and still lose order history. It can show the wrong price, or send orders to the warehouse without an address. Customers notice within hours. Your team then spends the first weeks after go-live fixing what testing should have found.

What is replatforming?

In e-commerce, replatforming means moving your online store from one commerce platform to another. Think of a move from one large suite to a composable setup. There, separate services handle commerce, content, search and login. Or from an old version of a platform to a new SaaS product. The word is also used for moving applications to the cloud, which is a different topic. Teams replatform when the old system holds them back. It is slow, hard to change or no longer supported. The front-end often gets rebuilt at the same time, and many integrations are moved or rebuilt along the way. That is exactly what makes it risky. In a normal release one thing changes and the rest stays stable. In a replatforming almost nothing stays the same, so you can’t rely on “it worked yesterday”.

Why do e-commerce migrations go wrong after go-live?

Most problems don’t show up on the new homepage. They show up in the parts of the chain that nobody looks at during a demo. These are the usual suspects:

• Data that moved, but not quite right. Customers log in and miss their order history. A product attribute arrives as plain text, so the filter that used it stops working.
• Integrations that were tested once. The connection to ERP, stock or the payment provider worked at the first test. Then a field changed and nobody ran the test again. At e-commerce clients we see this often.
• Several suppliers, no owner of the whole. An agency builds the front-end, a vendor runs the platform and IT runs ERP. Each tests its own part. Nobody tests the order from start to finish.
• Test data that changes underneath you. Shared test environments change all the time, so tests fail without a real bug and people stop trusting them.

What should you test in a platform migration?

Test the chain the way your customer uses it, from the first search to the order in the warehouse. A customer doesn’t see your systems. They see one order that either works or doesn’t. Work through these parts, starting with the ones that would hurt most if they broke:

• Search and product data. Products, prices, variants, filters and search results match the source.
• Prices, promotions and stock. Discounts, bundles and availability follow the same rules as before. Test these at API level, where they are fast and stable. Our article on API testing shows how.
• Accounts and login. Existing customers can log in, reset a password and see their history.
• Basket, checkout and payment. Every payment method, including failed and cancelled payments, and the connection to your payment provider.
• Orders after checkout. The order reaches ERP, warehouse and customer service with the right data.
• Old URLs. Redirects from old product and category pages. Google recommends permanent redirects from every old URL to its new one, and checking them before and after the move.

How do you test migrated data?

Counting records is not enough. The numbers can match while the content is wrong. Compare samples field by field: take a few hundred products, customers and orders, and check them on the old and the new platform. Pick the difficult ones on purpose, such as products with many variants, customers with long histories and orders with returns. Then test what customers do with that data: log in, reorder, filter, check out. Run the data migration more than once before the real switch. Then you test the result and fix the script, not the data by hand. Most platforms have import tools for this, such as the commercetools Import API. Whatever the tool, the test question stays the same: does the customer see what they saw before?

How do you prepare the switch itself?

Treat go-live day as a test you can rehearse. Three things make the difference:

1. Run the same regression tests on the old and the new platform. The old platform tells you what “right” looks like. Differences show up early instead of on launch day.
2. Rehearse the switch. Run the full cut-over on a test environment, with the data migration, the redirects and the checks afterwards. Time it, so you know how long the real one takes.
3. Agree on the checks for the first hours and days. Test orders with every payment method, orders arriving in ERP, a sample of redirects, and the number of failed payments compared with a normal day.

All of this works best when you automate the tests while you build the new platform, not after go-live. Automated tests let you rerun the data checks after every trial migration and run the same regression on both platforms as often as you like. They grow with the project, so by the switch they cover the chain. And after go-live they simply keep running. The new platform keeps changing, with new releases from the vendor, new features and new integrations. The tests that protected the switch protect every release after it, as long as someone keeps them running. We see the same pattern often: coverage stalls a few months after a big rollout, because nobody planned the maintenance. Our article on regression testing explains how to keep one running.

What this means for your team

Start with a map of your chain: every system the order passes through and every connection between them. Mark who owns each part, and notice where nobody does. That gap is where a migration usually goes wrong, and it is the part no single supplier will test for you.

That is where we help teams. We have tested complete e-commerce platform migrations, including checkout and payment and the connections behind them. We test across suppliers, so the chain is checked as one. Read more on our e-commerce testing page. With Test Automation as a Service we build that automation alongside your team while the migration runs, and keep it running every night after go-live. You get a stable test suite your team can trust, one that doesn’t depend on a single person or add to your team’s workload.

Frequently asked questions

What is the difference between replatforming and rehosting?

Rehosting moves an application to new infrastructure without changing it, often called lift and shift. Replatforming changes the platform itself. In e-commerce that usually means a new commerce system, migrated data and rebuilt integrations, so it needs far more testing.

How long should you test a platform migration?

Plan testing from the start of the project, not in the last weeks. Start with the integrations and the data migration as soon as they exist, and run the full regression on both platforms well before the switch. The rehearsal of the cut-over comes last.

Can you automate migration tests?

Yes, and for a migration you should. Data comparisons, API tests and the key customer journeys can all run automatically and repeatedly. Build them from the start of the project. Then you can run the data migration and the checks many times before go-live, and keep the tests afterwards.

What do you check in the first week after go-live?

Check orders with every payment method and orders arriving in ERP and the warehouse. Watch failed payments, customer service contacts and errors on redirected URLs. Compare each with a normal week on the old platform.