September 24, 2026
September 24, 2026
Replatforming is the only major IT project where success is measured by nothing happening. Orders keep flowing, rankings hold, customers do not notice. When it goes wrong, the damage rarely appears on launch day. It surfaces four to six weeks later in a search traffic chart, long after the project has been signed off and the team has moved on.
Most migration checklists list tasks. This table lists consequences, which is the more useful way to allocate attention. The items at the top are cheap to prevent and expensive to repair.
The first two rows account for most replatforming disasters. Both are preventable with work that must happen before the new platform is built, not after. That sequencing is the single most important decision in the whole project.
Replatforming is expensive, slow and risky. It is justified when the current platform is the constraint on the business, and not when the current implementation is simply badly maintained. Those two look similar from the inside and have completely different remedies.
Signals that genuinely point to replatforming:
The platform cannot express your commercial model. Account-specific pricing, contract catalogues, quote to order flows and multi-tier approvals are common examples in B2B trade, and most consumer platforms handle them only through fragile workarounds.
You are blocked from a market you have decided to enter, because the platform cannot support the required tax model, language, currency or local payment rails.
The vendor has announced end of life, or your version is out of support and the upgrade path is effectively a rebuild anyway.
Total cost of ownership has inverted, where licence plus the cost of maintaining customisations now exceeds the cost of a platform that supports your requirements natively.
Signals that point somewhere else:
The site is slow. Performance is usually an implementation and hosting problem rather than a platform problem, and it is often fixable for a fraction of a migration budget. Establish where the time is actually spent before concluding the platform is at fault.
Search and merchandising are weak. These are frequently replaceable as separate services without touching the platform underneath.
A new team dislikes the existing stack. This is a real cost, but it is a hiring and documentation problem, and replatforming for that reason alone tends to reproduce the same situation with the next team.
If you are still deciding between configuring a packaged platform and building to your own requirements, our comparison of low-code versus custom software development works through the criteria before you commit budget.
Almost every article on this subject leads with numbers. The most repeated are that 20% to 50% of organic traffic is lost after migration, that 30% to 60% disappears in the first three months, and a frequently cited claim that a majority of pages that lose rankings never recover them.
We tried to trace these to primary sources before using them, and could not. The traffic loss ranges appear on vendor blogs without a study, a sample size or a methodology. The most widely circulated recovery statistic is attributed to a well known SEO tool but does not appear in that company's published research in the form quoted. Numbers of this kind circulate because they are useful in a sales conversation, not because they were measured.
There is a more defensible way to think about the risk, and it takes an afternoon rather than a citation.
Estimate your own exposure:
The output is a range specific to your catalogue, built on your own data. It tells you how much redirect precision is worth, and it is defensible in a board paper in a way that a borrowed percentage is not.
The projects that fail are rarely the ones that underestimated the percentage. They are the ones that treated search visibility as a task for the launch checklist rather than a design constraint from the first architecture meeting.
This section is worth getting right because it is where most agency guides are weakest. The authoritative source is Google's own documentation on site moves with URL changes, and its guidance is more specific than most summaries of it suggest.
What Google actually says:
Three practical consequences follow from that guidance.
The redirect map is a deliverable, not a task. It should be produced before development starts, from a full crawl of the live site combined with Search Console and analytics exports, so that URLs with no internal links but real search traffic are not missed. Every old URL maps to the single most relevant new URL. Mapping everything to the homepage is the most common and most damaging shortcut, because it tells Google the old page has no equivalent.
Redirects are infrastructure with a one year minimum lifespan. Build them into the platform configuration or the CDN layer, document them, and put a calendar reminder before anyone is allowed to remove them. Redirect chains should be collapsed so each old URL reaches its destination in one hop.
Both properties stay verified. Keeping the old property in Search Console is what lets you distinguish between pages that moved cleanly and pages that fell out of the index, during the exact window when that distinction is actionable.
Two further items belong in the plan and are routinely forgotten. Structured data has to be reimplemented on the new templates rather than assumed to carry over, because product, offer and review markup often drives how listings appear. And internal links inside body content should be rewritten to point at final destinations instead of relying on redirects, since a site that resolves its own links through hundreds of redirects wastes crawl budget and slows every page.
Because this work spans engineering and marketing, it fails when neither owns it. Assign one named person accountable for the redirect map, sitting across web application development and the digital marketing side, with authority to delay launch if the map is incomplete.
Scope is usually underestimated because teams inventory the catalogue and forget everything attached to it. Use this as the migration inventory.
Order history and password hashes are the two that most often turn into launch incidents. Decide both in the first two weeks, in writing, with support and finance in the room.
Integration work is usually the largest hidden cost. A catalogue moves once, but an ERP or POS connection has to keep working continuously through cutover, which means dual running and reconciliation. This is where system integration effort concentrates, and it is the line item most often underestimated in a fixed price quote.
A migration plan written for a European or North American retailer will be wrong in this region in three specific ways.
Regional payment behaviour is not a variation on card payments. It is a different mix in every market, and narrowing the mix during a replatform is a silent revenue loss.
According to the Worldpay Global Payments Report 2026, as summarised for the region, digital wallets accounted for 40% of Singapore ecommerce value in 2025, with cards at 44%. In the Philippines, wallets reached 41%, with cash on delivery still at 23% and account to account payments at 13%. Account to account payments made up 44% of Thai ecommerce value. In Vietnam, cash on delivery still accounted for 16%. Malaysia's wallet share stood at 26%, and Bank Negara Malaysia reported 2.6 million DuitNow QR acceptance points by the end of 2024.
The practical rule is to inventory every payment method currently in use, including the ones with low volume, and confirm each is available on the destination platform before selection rather than after. A method that carries three percent of orders is still a full percentage point of annual revenue in a business with thin margins, and cash on delivery in particular carries operational logic around reconciliation and failed deliveries that does not port automatically.
Migrating customer records is a transfer of personal data. Under Singapore's Personal Data Protection Act, accountability stays with your organisation even when a vendor performs the processing, so the migration needs a written data processing arrangement with the implementation partner, clarity on where data resides during and after the move, and deletion of the intermediate copies that migrations always create. Staging environments loaded with real customer data and then forgotten are one of the more common causes of avoidable exposure.
Consent records deserve particular attention. Marketing consent is not a boolean that can be assumed. It has a source, a timestamp and a scope, and losing that provenance during migration means losing the ability to demonstrate consent later.
Regional peak events are concentrated and predictable: 9.9, 10.10, 11.11, 12.12, Ramadan and Hari Raya, Chinese New Year, and the year end period. Two rules follow.
Never launch inside a peak window, and never launch in the four weeks before one. The second is the rule teams break. A migration that launches in mid October has not been through a real load event before 11.11, and the first genuine stress test of the new platform is also the highest revenue day of the quarter.
Load testing should model the actual peak shape rather than a smooth ramp, because regional flash sale traffic arrives as a step function at a published minute. Where autoscaling is part of the answer, test that the scaling policy reacts fast enough for a step, which is a different question from whether it can eventually reach the required capacity. That is a cloud hosting design question, and it must be settled before launch rather than discovered during one.
The structure below is deliberately conservative, because the cost of a failed ecommerce cutover is asymmetric.
Phase 1. Discovery and inventory, three to five weeks. Full crawl of the live site. Export of Search Console and analytics data. Inventory of every integration, payment method and data domain. Decisions on order history and password hashes. The output is a written scope with the redirect map already in progress.
Phase 2. Platform selection and architecture, two to four weeks. Selection against the inventory rather than against a feature list. Confirm payment method coverage, tax model and data residency before commitment. Design the integration layer and the rollback path at the same time.
Phase 3. Build and data transformation, eight to sixteen weeks. Product and customer data transformation with reconciliation counts at every step. Template development with structured data implemented, not deferred. Redirect map completed and loaded into the destination configuration.
Phase 4. Testing, three to five weeks. Functional testing against the commercial model, not just the happy path. Payment testing for every method including failure and refund flows. Load testing against a modelled peak. A full dress rehearsal of the cutover on staging, timed. Structured quality assurance and testing matters more here than on a normal build, because the failure mode is lost orders rather than a visible bug.
Phase 5. Cutover and stabilisation, one week plus ninety days. Launch in a low traffic window with the old environment kept warm and a documented rollback decision point. Then monitor daily for the first fortnight and weekly to ninety days, watching indexation of new URLs, redirect errors, checkout completion by payment method, and revenue by landing page against the pre-migration baseline.
The ninety day tail is part of the project, not an afterthought. Google's own guidance is explicit that visibility fluctuates during a move and settles over time, which means the first fortnight cannot tell you whether the migration succeeded. Budget for the team to still be available in month three.
For organisations moving systems rather than rebuilding them, the same discipline applies to infrastructure transitions, which our remote system migration service handles under the same phased structure.
Three principles keep a replatforming budget honest.
Budget the transformation, not the transfer. Moving data is cheap. Reshaping an attribute model, reconciling a customer base and rebuilding a tax configuration is where the effort goes. When a quote appears low, this is usually the part that has been assumed away.
Hold a contingency and name it. Migration projects overrun for structural reasons, principally because the condition of the legacy data is unknown until work starts. A contingency in the range of a quarter to a third of the build estimate is a realistic planning assumption rather than a sign of a weak plan. Publish it as a contingency rather than hiding it inside line items, so that using it is a visible decision.
Price the ninety day tail explicitly. Support after launch is where migrations are rescued. Contracts that end at go live create an incentive to declare success on the day the site is visible, which is precisely the wrong moment to measure.
Two questions separate a credible implementation partner from an optimistic one. Ask when they produce the redirect map, and refuse any answer later than the start of development. Then ask what their rollback plan is, and require it in writing with a named decision point and a time limit.
Conclusion
If a replatform is on your roadmap for the next twelve months, the highest value thing you can do this month costs almost nothing. Run a full crawl of the current site, export twelve months of Search Console data, and identify which URLs carry your organic revenue. That single artefact determines how well the migration protects what you already have, and it is useful regardless of which platform you eventually choose.
Serdao has built and integrated web applications for eighteen years, from a delivery centre in Ho Chi Minh City. We are not a reseller for any commerce platform, which means our recommendation on where you should move is not a function of what we are licensed to sell.
Talk to our team about a migration readiness review, or see how our software development practice structures projects of this shape.
How long does an ecommerce replatform take?
For a mid-sized catalogue with standard integrations, seventeen to thirty weeks from discovery to a stabilised launch is a realistic planning range, of which build is typically half. The variables that move the number most are the number of integrations, the condition of the legacy data, and how many people must approve a release. A quoted timeline that omits a discovery phase is describing a build, not a migration.
Will we lose search traffic?
Some short term fluctuation is expected, and Google states this directly in its site move documentation. The size and duration depend almost entirely on redirect completeness and on whether content and structured data were preserved. The widely quoted loss percentages should be treated with scepticism, because they are published without methodology. Model your own exposure from your own Search Console data instead.
Can we migrate customer passwords?
Only if the hashing algorithms are compatible between platforms. Confirm this in the first fortnight. If they are not, plan a communicated reset with a clear explanation to customers, and expect a temporary dip in returning customer conversion. Discovering this late is worse than the reset itself, because it removes the chance to prepare the communication.
Should we redesign at the same time?
Preferably not. A simultaneous replatform and redesign makes diagnosis impossible, because when traffic moves you cannot tell whether the cause was the technical migration or the new templates. If both are genuinely required, sequence them and leave enough time between for the first to stabilise.
What about order history, is it worth migrating?
In most cases yes, at least for a defined recent period. Teams cut it to save budget and then discover that support cannot process returns, finance cannot reconcile, and customers cannot see what they bought. If full migration is genuinely not viable, keep the old system available in read only mode for a stated period and make that decision consciously rather than by omission.
How do we handle multiple Southeast Asian markets on one platform?
Decide early whether markets share a catalogue or maintain separate ones, because that choice drives URL structure, and URL structure drives the redirect map. Confirm that the destination platform supports the tax model and the payment methods of every market you operate in, not just the largest one. The market with the smallest revenue is usually the one with the requirement that nobody checked.