E-commerce replatforming and how to keep rankings

Replatforming an e-commerce site can mean two different jobs. This article is about the case where your store already runs on an engine you own and you are thinking about switching to a different one. WooCommerce to a custom build, OpenCart to Laravel, an aging bespoke system to a modern framework.

If you are leaving a rented platform where the engine does not belong to you, the job is different and so are the constraints. Everything there depends on how complete your export is before the account closes. That case has its own guide on moving from a platform to your own website. What follows is about moving between systems you control on both ends.

Separate the symptom from the cause

Start with a list of specific problems. “The platform no longer fits” helps nobody. Useful entries are concrete: stock levels lag by an hour, a filter generates too many queries, an operator retypes addresses into the courier system by hand, and changing one discount rule takes several days.

A store is designed around its data and its operations, and the platform only supports that model. If the model itself is wrong, the name of a new product will not save it. But if the process is described clearly and the system still forces you to build ever more elaborate workarounds, you have grounds to cost a migration.

What is usually fixed without moving

A slow page may come from a heavy theme, unoptimized images, a poor query or an underpowered server. A conflict after an update is often an abandoned module without support. Chaos in the admin area is usually caused by excessive permissions and duplicated fields. All of that is solved by an audit, a clean-up of dependencies and a change to how releases are deployed.

Even a large catalog does not prove the need to move. What matters is how filtering works, how many variants exist, how often synchronization runs and how good the queries are. Measure the slow operations, the table sizes, the background job queues and the load at peak first. Once you do, it almost always comes down to a few bottlenecks.

What points to a structural limit

A limit is structural when it shows up across different functions and forces you to work around the base model every time. Say the store operates as a B2B portal with individual contracts, credit limits, several approval levels and a single order split across warehouses. When every operation needs its own bolt-on, total complexity outweighs the convenience of any one module.

The second signal is being unable to change the system safely. The code has no boundaries, modules hook into the same events and override each other, there is no test environment, and updates are only possible during a long window of downtime. Some technical debt can be cleared. But when rebuilding the foundations approaches the scale of a new build, it starts to make sense to compare platforms.

When the move would be premature

Do not migrate because the design looks dated. The interface is updated separately, keeping the data and the integrations. Do not change platforms over one disappointing module before the team has tested an alternative. Weak sales do not point to a technical limit either. Check traffic quality, the offer, stock availability and the checkout flow first.

A move is also premature when the requirements are not written down. Without a map of the processes, the new system gets built from random examples of the old one. The team repeats familiar flaws and discovers the missed exceptions at acceptance. A short discovery phase before the decision costs less than a migration you have to redo.

Treat “the new platform is faster” with caution. Speed depends on implementation, data, infrastructure and load. You need a target figure for specific pages and operations, and a test on the real catalog. A general promise is not evidence.

If you are still choosing between engines rather than moving, compare them first: OpenCart vs WooCommerce.

How changing your own engine differs from leaving a rented one

The difference is not cosmetic, and it is why a plan written for one case fails in the other.

• You already hold the data. Nothing has to be exported before an account closes. The database is in hand, and you can run as many trial migrations as you like.
• The old system can stay alive. That is the basis of a rollback plan, which a platform exit usually cannot have.
• The URL structure is yours to control. The new engine can be made to serve exactly the addresses you had, rather than whatever a platform imposes.
• Integrations have to be rewritten. Accounting, delivery and payments were wired to the old engine, and every connection gets rebuilt.
• Modules do not move at all. Whatever your plugins did either exists in the new system or gets written. This is the most commonly underestimated line in the budget.

Capture the baseline before any work starts

Before changing anything, record the old store in detail. This part feels pointless right up until something goes missing, at which point there is nothing to restore it from.

• A full crawl. A register of every page: categories, filters, products, articles, utility pages. With response codes, canonical URLs, titles and descriptions.
• Pages with real traffic. A twelve-month list of pages with impressions, pulled through the Google Search Console API. An export straight from the report is capped at 1,000 rows, and an online store can have far more pages than that. This way no commercial page is lost because nobody remembered it.
• Baseline rankings. A snapshot of where your main keywords rank today, so there is something to compare against afterwards.
• A map of integrations. What connects to what, which way the data flows, how often, and who notices when a connection breaks.
• A copy of the database and files. Complete, working, with a restore you have actually tested. Kept in a place you can restore the site from. “Somewhere on the server” does not count.

Put it all in one table with the page type and the intended destination. Rules then apply by group, and exceptions get handled individually.

URL strategy

The single most important decision of the whole move is taken here, and it is rarely reversible later.

Because you control both ends, the first scenario is almost always available. The new engine can be taught to serve the same addresses even when its defaults would build them differently. The choice is between some routing work at the start and a long recovery of rankings later.

The second is justified when the old structure genuinely gets in the way: numeric identifiers in URLs, three levels of category nesting where one is enough, utility parameters sitting in the main path. Then the structure is corrected once, alongside the move, but with a complete mapping table.

The third is not a scenario but an accident. It happens when nobody thinks about URLs until after the release.

Mapping data between engines

Here is the main difference from a platform export. The data is not dumped to a file but mapped model to model.

• A field mapping table. What was an attribute in the old system may be a variant in the new one. What was free text should become a value from a controlled list.
• Identifiers are preserved. SKU and internal codes are the basis of every link to accounting and sales channels. Changing them breaks integrations silently.
• A trial run on the full catalog. The whole volume, because problems show up precisely in the rare cases that twenty products will not reveal.
• A discrepancy report. How many products transferred, how many were rejected and why. Without the report the difference surfaces a month later.
• Customers and orders. Purchase history and passwords transfer when the new system’s algorithm allows it. When it does not, plan the password reset in advance and warn people.

The scale of this work feeds straight into the online store estimate, and it is usually larger than expected, because nobody costed the old system’s modules.

There is no list price for a migration. The scope depends on the number of products, the depth of the integrations and how much functionality lived in the old system’s modules. We cost it against your catalog and your integration map, and put the figure in the contract before work starts.

Switchover day

On release day the order of operations is written down in advance and worked through point by point, not from memory.

• Lower the DNS TTL. To five minutes, a day before the start. That is what makes a fast return possible.
• Freeze catalog changes. For a short agreed window, so the final sync is complete.
• Run the final transfer. Orders and stock changes that reached the old store on switchover day have to end up in the new system.
• Switch the records. Then immediately confirm the certificate works across every subdomain.
• Lift the indexing block. The staging site was closed to search engines, and that block has to come off in production right after the switch.
• Walk the checklist. Home page, a category, a product, the cart, checkout and several old addresses.

Check from more than one network and from clean sessions. Caching and the content delivery layer can serve different versions, and on the work laptop everything will look right.

The rollback plan

This is the advantage a platform exit does not have, which is exactly why it should not be wasted.

• The old store stays alive for thirty days. On a separate server, in working order, with its database. The store can be switched back on if a rollback is needed.
• A low TTL before and after. It shortens the delay on the way back but guarantees nothing. Some intermediate resolvers hold the old record longer than the TTL you set.
• The decision threshold named in advance. Exactly what has to happen for the team to roll back.
• Someone on duty for the first hours. A developer and an administrator with an agreed response time and the authority to make that call.

Decide separately what happens to orders that arrive in the new store before a rollback. They must not disappear along with the switch back.

The fatal mistakes

• Nobody thought about URLs until after the release. This is the worst of them all. Old pages fall out of the index and years of accumulated authority reset to zero.
• The staging store was left open. A copy on a subdomain with no indexing block dilutes the main domain and creates duplicates.
• The indexing block was never lifted. The live store stayed closed to search engines, and pages gradually dropped out of the index.
• Modules were not costed. The budget covered moving the data, while half the functionality lived in plugins that do not exist in the new system.
• Meta tags were regenerated. Replacing carefully written unique titles with templated ones throws away years of work.
• The old system was switched off immediately. The rollback plan ceased to exist at the moment it was needed.

What comes after the switch

A migration does not end on release day. For the first four weeks, check more closely and review redirects, metadata, filters, structured data and server logs every day. How long search engines take to process the move depends on the number of URLs and the speed of the site, and nobody can predict it exactly.

That is a separate job with its own order of operations, covered in the follow-up: technical SEO after replatforming.

Conclusions

Changing the engine of a store you control can be planned and managed. You hold the full database, you can run trial migrations, and the old system stays as insurance. Those three things are what separate this move from leaving a rented platform.

What costs the most here is usually the order in which things get decided. URLs get considered after the release, modules go uncosted, the old system is switched off on the day. Each of the three is solved by a decision taken before the work begins.

Send us the store’s address and describe what it actually keeps running into. Given the structure, the traffic pattern and the server logs, we can say whether the engine is genuinely the limit or whether the bottlenecks can be cleared where they sit. If a move is needed, we build the URL map and the integration map before any work starts, and take the migration on as part of e-commerce website development.