A Replatforming Timeline That Holds: How to Plan the Platform Migration

Replatforming is one of those projects where timelines have the worst reputation – often deservedly. But it is rarely the technology that blows the plan. It is usually what was never in it: integrations that turned out to be more numerous than anyone knew, product data that needed cleansing, decisions that dragged on. A replatforming timeline that holds is, above all, one that is honest about where the uncertainty sits.

Here are the phases of a platform migration, what each phase should deliver and where buffers and decision points do the most good.

The phases of a replatforming – and what they should deliver

1. Pre-study and mapping

Before any timeline is written, three things need to be mapped: the integration landscape (every system that talks to the store today), the data (products, customers, orders, content – volume and condition) and the functionality (which of today’s behaviour is actually used and should come along). This is the phase most often skimped on, and it is exactly why timelines break later. If you are moving to HDL Commerce, this is done as a free migration analysis – a review of your specific environment before you commit to anything.

2. Solution design and requirements freeze

This is where the target picture is decided: information architecture, design, which integrations will run through ready-made connectors and which require customisation, and – most important of all – what is NOT included in phase one. A platform migration is the wrong moment to redesign the entire business model at the same time. Freeze the requirements at the end of this phase and move everything new to a phase-two list.

3. Setup and integrations

The platform is set up, the design is implemented and the integrations are built. The integration track should start first, not last – it is almost always the critical path. Ready-made connectors shorten the track considerably: HDL Commerce has ready-made connectors for systems including Business Central, Fortnox, Klarna, Swish, nShift and Skrym, listed on the integrations page. Every system without a ready-made connector should have its own line in the timeline with its own risk and its own buffer.

4. Data migration

Migrate in repeatable runs, not as a one-off move. The first run reveals the data deficiencies, the following ones verify that the fixes hold, and the last one is executed at launch. Plan the data cleansing as its own work package with its own owner – dirty product data does not disappear by changing systems.

5. Testing and acceptance

Test with real scenarios: real customer price lists, real shipping rules, real payment flows. Acceptance testing should be run by the people who will work in the platform, not just by the project. Book their time now – waiting for busy key people is one of the most common hidden delays.

6. Launch and stabilisation

Launch with a thorough checklist: DNS and redirects from old URLs, tracking, payment flows in production and a clear rollback plan. Then plan a stabilisation period with heightened monitoring – and count it as part of the project, not as an afterthought. It is during the first weeks after launch that rare order types, unusual payment combinations and edge cases in the integrations show themselves, and the team that built the solution should still be around with allocated time.

Run the tracks in parallel – with explicit dependencies

The phases above are not strictly sequential. Content production, data cleansing and integration building can and should run in parallel – but only if the dependencies are stated. The content team needs the information architecture from solution design, the integration build needs test environments and access to the source systems, and the data migration needs the attribute model to be finalised. A timeline that only lists activities without dependencies looks shorter than it is; it is the dependencies that determine the real critical path.

Where replatforming timelines usually break

• Unknown integrations. Excel flows, old FTP jobs and systems “only Lasse knows about” surface mid-project. The remedy is a thorough pre-study.
• Data cleansing without an owner. Everyone assumes someone else will fix the product data. Appoint one person with a mandate and allocated time.
• Decisions without deadlines. Design choices, assortment questions and pricing logic waiting for “the next meeting” eat weeks. Put decision points in the plan with a named decision-maker.
• Scope that grows in silence. Small “while we’re at it” additions are the single biggest time thief. Everything new goes to phase two.
• Content work gets forgotten. Copy, images and SEO redirects take longer than most people plan for and can start early, in parallel with the build.

Buffers and decision points – how to place them right

A wise timeline does not have one big buffer at the end but several small ones at the uncertain moments: after the first migration run, after the integration tests and before the launch decision. A buffer at the end only postpones the discovery of problems; a buffer at the point of uncertainty catches them while they are cheap to fix.

Also add a formal go/no-go point before launch with clear criteria: migration verified, critical flows tested with real data, redirects in place. That turns the launch decision into a check, not a hope – and it makes it legitimate to move the date if the criteria are not met.

What affects the duration most?

Three factors drive the calendar time more than anything else: the number of integrations without a ready-made connector, the condition of the product data and your own decision-making capacity. A platform with B2B and B2C in one core and a built-in PIM also removes entire work packages that would otherwise have to be assembled from add-ons – see the solutions for how different types of businesses have set up their projects. If you are moving specifically from Magento, there is a dedicated run-through of the differences on the comparison page.

Also calculate the total cost over the life of the project and its operations, not just the build cost – with open per-month pricing, as on our pricing page, that calculation becomes far easier to do honestly.

Start with the analysis, not the date

The best start to a replatforming is not to set a launch date but to gather facts. Book a walkthrough and we will do a free migration analysis of your current environment – integrations, data and functionality – and give you a timeline basis built on your reality. Get started here, and we will reply within 4 hours (weekdays).