When a new online store puts the business at risk: what matters when switching platforms
An online store migration affects day-to-day sales. What businesses should check before switching platforms and agree before launch.
Briony Kennedy wanted to take the next step with her online store. Her Australian cosmetics brand, Adorn Cosmetics, was profitable, customers could place orders, and advertising and search engines were bringing in visitors. That is how the founder now describes the position before a platform migration that was meant to move her business forward.
Adorn was selling through a free version of Magento. According to Kennedy, moving to Adobe's paid solution promised better security, higher performance and room for further growth. She says Adobe also recommended the implementation partner. It was a decision in which she relied on other people's expertise. In her account of the migration, one word therefore takes centre stage: trust.
In her later accounts, Kennedy links the migration to serious financial problems. She has made allegations against Adobe and the implementation partner, Convert Digital. In another public post, she describes steps her legal team is taking towards court proceedings. Her questions range from the choice of platform to launch readiness, SEO, advertising tracking and integrations. Responsibility has not been established. What is publicly available at this stage is the founder's account.
For other retailers, the case touches a sensitive point. Replacing a store means rebuilding the place where customers arrive, buy and pay. The business has to keep running throughout.
A promising start
The story does not follow a straight line from a working old store to a failed new one. In her November 2021 interview with Add To Cart, Kennedy sounded pleased with the move. She described how numerous extensions had made the old store slow and prone to errors. She praised Adobe's support, faster pages and new possibilities. Adobe also presented Adorn as a positive customer example in 2022.
Those early statements are part of the story, just as Kennedy's later allegations are. They show why a positive initial assessment does not settle how a project performs over time. The available accounts do not reliably establish which technical faults occurred at Adorn or who was responsible for them.
Meanwhile, Adorn continues to seek customers. On 8 November 2026, the Adorn store was accessible, displayed products and asked people to support the company. An accessible website does not answer the question of how the business is doing financially.
That distinction matters in a store migration. A website can be online while the business behind it is suffering.
When customers lose their familiar route
One customer follows an advert to a particular product. Another searches Google for an item number. A regular customer opens a saved link. For the retailer, these are established ways into the business. They can disappear during a migration even when the new homepage looks flawless.
If a product page's address changes, its old link needs a suitable new destination. Redirecting it to the homepage forces customers to start their search again. Along the way, an intention to buy can turn into an abandoned visit.
Google's guide to site moves explains how to map old and new addresses, prepare redirects and monitor the move. The casually phrased task of “bringing the SEO across” becomes a concrete project responsibility: which landing pages bring in customers, where will those customers arrive after the switch, and who checks?
After launch, looking only at the total number of orders is not enough. Are visitors from search missing? Do adverts lead to the right products? Are the reported purchases plausible? Google notes that rankings can fluctuate temporarily after URL changes. Sustained losses need investigating. Without a record of the position before the migration, it can be difficult to work out what changed.
An order is only the start of acceptance testing
The first successful test purchase can be just as misleading. The basket works, payment is accepted and the confirmation arrives. But what does that purchase tell you about a regular customer with agreed prices? A different payment method? Or the data the ERP system needs to process next?
Consider a business customer ordering a particular variant at an agreed price. The selection must be correct for that customer. The order then has to contain the right item reference, price and customer details. If an employee has to repair the order manually in the next system, the visible checkout has concealed part of the problem.
That is an example of a test case for a migration project. The cases a retailer actually needs depend on its business. The launch checklist for Adobe Commerce on cloud infrastructure explicitly includes user acceptance and performance testing. Their practical value lies in the real orders and failure cases the team works through before launch.
The intended improvement needs to be clear early on. Less manual rework is a different goal from opening new sales channels or improving product search. “More modern” leaves the business without a clear way to judge success later.
Who decides whether the store is ready?
The more companies are involved in a migration, the more precisely their responsibilities need to be defined. A platform provider supplies software, an implementation partner configures it, and the retailer knows its customers and commercial rules. Between those roles are decisions that no feature list can sign off.
Who confirms that a displayed price is commercially correct? Who checks the redirects? Who compares an order in the store with the order received by the next system? And who can stop the launch if something is wrong?
Every business-critical process needs someone to implement it, someone to assess the result and a clear sign-off. Test evidence must show what was expected, what actually happened and which discrepancies remain unresolved. That gives management a basis for its decision rather than a blanket assurance that everything is “finished”.
The planning also has to cover the morning after launch. Faults may appear that were not visible in testing. Contacts need to be available and know when a correction is enough and when the operation needs protecting.
A prepared way back is part of that plan. Once orders and payments start arriving in the new store, the clock cannot simply be turned back. Those transactions must be preserved and processed even if the business switches back. If returning to the old system is impractical, another workable contingency plan is needed. The Adobe Commerce Storefront checklist calls for a tested rollback plan and post-launch monitoring for the architecture it describes.
These are requirements for your own project. They are not a retrospective diagnosis of what went wrong at Adorn.
Five questions before switching
That leaves five questions to take into the next project meeting:
1. Which business problem should the migration solve, and how will we recognise an improvement? 2. Which purchase and failure cases must demonstrably work before launch? 3. Who checks existing landing pages, search traffic, advertising destinations and measurement data before and after the move? 4. Who implements the business-critical processes, who tests them, and who signs off the launch? 5. What do we do if something goes wrong, and what happens to new orders and payments?
The answers belong at the start of planning, including for a project using Shopcloud by schukai. The processes and acceptance criteria determine which components fit and which adaptations are needed.
For customers, the switch should ultimately be uneventful: they find their item, order it at the right price and receive their goods. The new store has to keep that familiar business going.