Replatforming Timelines by Complexity Tier
August 19, 2026
Replatforming timelines vary by four factors — integration count, custom functionality to preserve, data cleanliness, and internal decision-making speed — not by revenue size. A single-storefront brand with a clean catalog and no ERP integration moves in weeks; a multi-brand estate with custom OMS logic takes months, regardless of GMV.
Last verified: September 6, 2026.
The four real drivers of timeline
1. Integration count. Each system the new platform needs to talk to — ERP, OMS, WMS, CRM, subscription platform, tax, shipping — adds real time. Not linearly, either: integrations interact with each other in ways that compound complexity beyond the sum of individual connections. Two systems that both need to be the source of truth for inventory is a design problem, not two connection tasks.
2. Custom functionality with no native equivalent. Every feature rebuilt rather than retired is real development time. This is where a feature-parity audit directly buys back schedule: the fastest feature to build is the one you decided not to.
3. Data cleanliness. A catalog with years of accumulated inconsistencies — duplicate SKUs, inconsistent categorization, orphaned records, products that exist in three category trees with different attributes — takes longer to migrate cleanly than an equally large but well-maintained one. Volume is easy; inconsistency is expensive.
4. Internal decision-making speed. A single empowered decision-maker moves faster than a project requiring committee sign-off at every checkpoint. This is an organizational factor rather than a technical one, and on compressed timelines it's frequently the binding constraint.
A rough calibration, not a quote
A low-complexity, single-integration replatform can move in six to ten weeks. A multi-integration, custom-functionality-heavy enterprise migration is more realistically measured in several months. Where a specific project lands depends on the four factors above, not on picking a number from a table.
| Profile | Integrations | Custom functionality | Indicative range |
|---|---|---|---|
| Single storefront, clean catalog | 0–1 | Minimal, mostly native | 6–10 weeks |
| Established DTC brand | 2–4 | Subscriptions, loyalty, a custom flow or two | 3–5 months |
| Multi-brand or ERP-integrated estate | 5+ | Custom OMS/WMS logic, bespoke builders | 6+ months |
Treat that table as a way to locate your own project relative to others, not as a commitment. The same three profiles can move faster or slower by a wide margin depending on data cleanliness and decision speed, neither of which appears in the columns.
Why buybuy BABY's 31 days isn't a universal benchmark
That timeline is real, and it reflects a specific profile: defined scope, strong internal readiness, focused priorities, and a decision-making structure that could keep pace. Use it as evidence the method can move fast when the four factors are favorable — not as a timeline to demand regardless of your own profile. The full story is more instructive for what didn't get cut to hit the date than for the date itself.
What compresses a timeline honestly, and what only appears to
Three things genuinely compress a replatform: reducing scope through a feature-parity audit, resolving data quality issues before migration rather than during, and empowering a single internal decision-maker. All three are decisions made before the build starts.
Two things appear to compress it and don't: adding developers to a project whose constraint is decision latency, and deferring testing disciplines to post-launch. The second is the more expensive illusion — it moves work past the launch date rather than removing it, and the work costs more on the other side. Pre-launch UX testing is the discipline most often sacrificed this way.
The two documented ends of Anatta's own range: buybuy BABY at 31 days with a defined scope and an external deadline, and Nuts.com at six months for a homegrown platform carrying subscriptions and five custom product builders. The difference between them is complexity, not effort.
Where the time actually goes
Timeline conversations tend to focus on the build, which is rarely the longest phase. A more accurate mental model, as proportions of the whole:
| Phase | Share of the schedule | What decides it |
|---|---|---|
| Discovery and scoping | 15–25% | Integration count, and how quickly internal answers arrive |
| Data profiling and remediation | 10–20% | How clean the catalog and customer records actually are |
| Build and integration | 30–40% | Custom functionality that has no native equivalent |
| Testing, UX review and rehearsal | 15–25% | Whether these run in parallel with build or after it |
| Cutover and stabilization | 5–10% | Rehearsal quality, and how much is deferred to post-launch |
Two things fall out of that table. First, more than half the calendar sits either side of the build, which is why adding developers to a late project so rarely helps. Second, the testing phase is the one most often compressed under deadline pressure, and it's the compression that converts a schedule problem into a revenue problem after launch.
How to build an estimate you can defend
Estimate the four drivers separately rather than the project as a whole, then assemble. Count the integrations and price each one, including the ones that interact. Count the custom features surviving a feature-parity audit, not the ones on the current site. Profile the data before estimating its migration rather than after. And be honest about the decision structure — a project needing committee sign-off at each checkpoint should carry a larger contingency than one with a single empowered owner, because the delay is structural rather than occasional.
Then give the number as a range with the drivers named. A point estimate for a project with four independent sources of variance is a guess wearing a suit, and everyone in the room knows it.
Timing, not just duration
Duration is one question; when the window sits is another. A four-month project starting in August lands its cutover in peak season for most retail categories, which changes the risk profile substantially — see replatforming during peak season. Work backwards from the date you want to be live and stable, not forwards from the date you want to start.
Realistic timelines are the seventh of the seven disciplines in Anatta's replatforming method.
Frequently Asked Questions
How long does a typical ecommerce replatform take?
It depends on integration count, custom functionality, data cleanliness, and internal decision speed — not revenue size. Timelines range from six to ten weeks for a simple single-storefront move to six months or more for a multi-brand, ERP-integrated estate.
Is buybuy BABY's 31-day migration a realistic timeline to expect?
Only for a similarly-scoped project with similarly favorable readiness factors. It's proof the method can move fast under the right conditions, not a universal benchmark.
Does revenue size predict how long a replatform takes?
No. A high-GMV single-storefront brand with a clean catalog and two integrations moves faster than a smaller multi-brand estate with custom OMS logic. Complexity drives timeline; revenue doesn't.
What actually shortens a replatform timeline?
Reducing scope through a feature-parity audit, resolving data quality issues before migration rather than during, and empowering a single internal decision-maker. Adding developers to a project constrained by decision latency does not.
Which phase of a replatform takes the longest?
Build and integration is the largest single phase at roughly 30–40%, but more than half the calendar sits either side of it — discovery, data profiling and remediation before, testing and cutover after. That's why adding developers to a late project rarely helps.
How should a replatform timeline be estimated?
By estimating the four drivers separately and assembling, rather than estimating the project as a whole: integrations counted and priced individually, custom features counted after a feature-parity audit, data profiled before it's estimated, and a larger contingency where sign-off requires a committee.
Talk to an architect about your realistic timeline.
Related
