Menu
Replatforming
Most replatforming projects go wrong in the parts nobody scoped: catalogue data, URL continuity, and the integrations that quietly hold the business together. We map those first, in writing, so you can decide with the real numbers in front of you.
What you get
A written migration plan covering catalogue and customer data mapping, URL and SEO continuity, integration inventory, and a phased cutover sequence. Delivered before any build work is quoted.
A written document, not a call summary. This is the structure every migration plan follows, with example values in place of your data.
| Checked | Example finding | Rating |
|---|---|---|
| Catalogue entities mapped | products, variants, option setsIncluded | Included |
| Attributes without a target | 14 requiring a decisionHigh | High |
| Integrations inventoried | ERP, PIM, tax, payment, reviewsIncluded | Included |
| Integrations needing rebuild | 3 of 11Critical | Critical |
| URLs crawled for redirect map | full crawl, not sitemapIncluded | Included |
| Redirect chains found | 2 hops on 40 URLsMedium | Medium |
| Cutover phases | 5, with rollback per phaseIncluded | Included |
plus the full data-mapping table and phase-by-phase sequence
Example values shown. Your report contains findings from your own environment.
Every attribute, option set, and customer record traced from the source schema to the target. This is where migrations lose weeks, and it is the first thing we document rather than the last.
A complete redirect map from old URLs to new, plus canonical and structured-data parity. Replatforming is the single most common way a store loses its organic rankings overnight, and it is entirely avoidable.
ERP, PIM, tax, shipping, payment, reviews, email, and the one custom script someone wrote four years ago. We list what exists, what has a native equivalent on the target platform, and what needs rebuilding.
What ships first, what runs in parallel, and what the rollback looks like at each stage. Written so your team can evaluate the risk, not just accept it.
For a mid-market catalogue with standard integrations, plan on three to six months from kickoff to cutover, with the migration plan itself taking two to three weeks. The variables that actually move that number are catalogue complexity (configurable products and option sets far more than raw SKU count), the number of live integrations, and whether the business can freeze feature work during the cutover window. Enterprise B2B builds with custom pricing logic, contract catalogues, or multi-site requirements run longer. Six to twelve months is realistic. We would rather give you a defensible range after seeing your integration inventory than a confident number before. The plan phase exists precisely so the build estimate is grounded in what is actually there, rather than in what a discovery call surfaced.
You can, and most stores that lose rankings during a replatform lose them for preventable reasons: URLs changed without redirects, redirect chains more than one hop deep, structured data dropped from product templates, or the new platform rendering key content client-side where it had been server-rendered. None of that is inherent to migrating. We build the redirect map from a full crawl of the existing site rather than from the sitemap, because the sitemap almost never lists everything that has inbound links. We also keep canonical tags and product schema at parity across the cutover, and stage the new site behind authentication so it cannot be indexed early. Ranking dips of a week or two around a cutover are normal; sustained losses are a scoping failure.
Yes, and for larger migrations that is usually the better arrangement. Your team knows the business logic and the history behind the odd decisions in the codebase; that knowledge is expensive to transfer and easy to lose. A common split is that we own the migration architecture, the data mapping, and the platform-specific build, while your team owns the integrations they already maintain and the QA against real business processes. What matters more than the split is that one person is accountable for the cutover sequence. We can hold that or support someone on your side who does. But it should be explicit before work starts, not assumed.
This page covers one specific engagement. The service page has the complete scope, process and technology list.