Enterprise replatforming: planning scope, decisions and cutover

A change is justified when the platform itself causes your problems. Solid reasons look like this: the vendor discontinues your version, every business change strictly requires a developer, or a new model such as subscriptions or B2B cannot be represented cleanly in the existing data model.

The most common false reason is dissatisfaction with the storefront. Dated design, slow pages or weak search can almost always be fixed without changing platforms. Replatforming for those reasons trades a known system for an unknown one and carries the real legacy of data, processes and ownership along untouched.

Before deciding, check how much of your pain sits in the software and how much sits in data quality, processes or unclear responsibilities. If the larger share sits outside the platform, a change will not solve it. It moves the problem into a new system, where it becomes visible again at a higher price.

Improving what you have is usually the better answer when the store works commercially and only jams in specific places. A well maintained catalog, a checkout that converts and a working ERP connection are assets. A replatforming resets exactly those three things to zero.

A useful test is the list of open requirements from the past twelve months. If most of them could be built in the current system and only failed on budget or priority, you do not have a platform problem. If they failed on the limits of the system itself, the case for a change holds.

Partial replacement is possible and consistently underrated. Rebuilding the storefront while keeping the backend, replacing the checkout, adding a PIM in front, or rebuilding a single market separately often solves the same problem without moving the whole business onto new ground in one day.

A big bang is defensible when your store is contained: one market, one assortment, few integrations. Running two systems in parallel then costs more than the risk. As soon as several countries, brands or customer segments are involved, the number of cases to verify at once grows faster than any test budget.

Gradual replacement buys safety with parallel operation. Two systems mean two maintenance paths, two states of the data and colleagues who have to check where an order actually lives. That is manageable when the period is named up front. Without a fixed end date, the interim step quietly becomes permanent.

The cut should follow a boundary that already exists in the business. A separate country store, an independent brand or the B2B business each has its own customers, prices and often its own processes. An artificial cut straight through one customer group creates cases nobody can describe in advance.

The most expensive delays in replatforming projects come from waiting for decisions, not from writing code. When nobody is named who finally rules on pricing logic, customer master data or the returns process, every question turns into another round of meetings, and every round costs a sprint.

Before the build starts, it must be clear which system holds the truth for which object. Products, inventory, prices, customers, orders and documents each need one leading source. Without that, you build interfaces that overwrite each other, and corrections end up being made by hand in daily operations.

A short list of decisions with names and timing, visible in the project room, does real work. Not as a formality, but because it shows where the project actually stands. Open decisions are the most reliable early indicator of a launch date that is about to move.

Legacy data is rarely a technical problem and almost always a commercial one. A catalog built over ten years contains products without images, duplicate customers, variants only one colleague understands, and attributes created once for a campaign. That substance determines how long a migration takes.

Decide early and in writing what comes along. Active products and customers belong in the new store, order history often only as a read only view, old campaign pages usually not at all. Anything migrated without a purpose has to be tested, maintained and corrected again later, permanently.

Integrations are the actual core of an enterprise replatforming. ERP, PIM, marketplaces, returns portal and customer service all hang on fields nobody has documented in years. Before the build starts, every connection needs a clear owner, a defined set of objects it moves, and a named contact for failures.

Visibility comes out of decisions made early: URL structure, category architecture, how filter pages behave, language and country logic, how the storefront renders. If SEO is planned as an acceptance checkpoint shortly before launch, those decisions can only be commented on, not changed.

A redirect concept is mandatory, but it is the smaller half. Google describes a domain or URL change as a site move in which old addresses should point permanently to their matching new ones. That saves addresses. It does not save a page whose content disappeared during the rebuild.

In practice: take an inventory of pages with rankings, links and revenue before the build, map old to new, and build the templates against that mapping. After launch, indexing, error pages and rankings belong in a fixed monitoring routine for several months.

The cutover window is the period in which the old store no longer leads and the new one is not yet fully working. The critical part is not pages but transactions in flight: open orders, returns, gift cards, subscriptions and everything currently moving between store and ERP.

Schedule the window in a low demand period, but not one where nobody is reachable. A Friday evening cutover saves revenue and costs response time. More important than the weekday is that development, ERP support, payment providers and customer service are genuinely available during the same hours.

Describe the way back before you start. What happens if inventory sync returns wrong values after two hours? A rollback is only possible as long as no orders exist in the new system. After that, the only option is repairing forward, and you want to know that in advance.

The first warning sign is usually linguistic: a fixed date turns into a period, and a period turns into an intention. When status meetings stop covering finished functionality and start reporting progress in percent, the project is missing a shared definition of what done means.

The second signal is growing scope against an unchanged launch date. Every extra requirement accepted without dropping something else is a silent postponement. It only becomes visible once the buffer is gone, which is usually shortly before the planned launch.

The third signal is testing pushed toward the end. When integrations are only tested after every template is finished, the project accumulates risk exactly where it is most expensive to fix. Early, incomplete test runs are more uncomfortable and considerably cheaper.