The High Cost of Standing Still
The accepted wisdom for enterprise replatforming projects is flawed. A multi-month code and feature freeze is often presented as an unavoidable technical necessity. For senior leaders, this should be unacceptable. For a complex B2B business like a builders merchant or an industrial distributor, a six-month pause on digital evolution is a significant, self-inflicted liability. Your competitors will not wait for you. Your customers' expectations will continue to rise. A replatforming freeze is not a cautious strategy; it is a tactical retreat at a moment when you should be advancing.
The cost of this freeze is concrete and measurable. It is not merely the opportunity cost of features you could have shipped or optimisations you could have made. The damage is deeper. Team momentum, built over years, evaporates. Business stakeholders, initially enthusiastic, become frustrated and disengage. And critically, risk accumulates. Every day the freeze continues, the 'big bang' launch becomes a more complex, higher-stakes event. Based on our experience with large-scale rescue projects, we know that the longer the gap between the last data sync and the go-live, the greater the probability of a catastrophic failure on launch day.
An Alternative: Continuous Synchronisation
The antidote to the risk of a 'big bang' is the dual-write pattern. The concept is straightforward. When a key business event occurs in your legacy system, it writes the resulting data to two places simultaneously: its own database, and, via an API, to the database of the new platform you are building. This is not a one-off data migration performed late at night. It is a continuous, real-time process that begins early in the replatforming project.
This pattern ensures that as your new platform is being built, it is being populated with clean, live production data. When a customer service agent creates a new trade-account in the old system, that account appears moments later in the new one. When a customer places an order, that order is recorded in both systems. This approach, a practical application of the 'strangler fig' pattern, means the new system is 'warm' from day one. By the time you are ready for launch, the new platform has been processing real-world data, under production-like load, for months. The final launch is no longer a migration of data, but a simple change in DNS.
"A replatforming freeze is not a technical necessity. It is a failure of architectural imagination and a six-month, self-inflicted wound on your ability to compete."
Dual-Writes in Practice for B2B Commerce
In the context of B2B commerce, especially on a platform like Adobe Commerce, the implementation must account for significant data complexity. For a builders merchant, a 'customer' is not a single record but a web of related data: multiple users with different permissions, specific contract pricing, job account credit limits, and delivery addresses. A successful dual-write implementation must handle this entire object gracefully. When a sales representative updates a customer's credit limit in the ERP, that event must trigger a write that updates the corresponding customer in the new Adobe Commerce instance.
Resilience is paramount. The legacy system cannot fail or slow down if the new platform is temporarily offline for maintenance. To solve this, we engineer these integrations asynchronously using a message queue, a standard component of Adobe Commerce through its integration with RabbitMQ. The legacy system's only job is to publish a 'customer_updated' or 'order_created' message to a queue. Separate, independent worker processes pick up these messages and manage the communication with the new platform, including logic for retries and error handling. This decouples the two systems completely, which is essential for stability during a long-term transition. The pattern is well documented in commerce engineering practice; applying it to complex B2B data is the part that takes experience.
The same pattern applies to catalogue data. When product information is updated in a PIM or ERP, the dual-write system ensures both the old and new commerce sites receive the update. This allows you to continue merchandising and managing your catalogue on your live site, safe in the knowledge that all changes are also being reflected on the platform-in-waiting. This eliminates the need for a last-minute, panicked effort to reconcile months of catalogue changes before launch, a common point of failure in traditional replatforming projects.
The Honest Trade-Offs and Pre-requisites
This strategy is powerful, but it is not without its costs and pre-requisites. It represents a significant upfront investment in architecture and engineering. Compared to a simple CSV export and import, it is more complex. The primary requirement is that your legacy system must be extensible. It must be possible to modify its code or use existing extension points ('webhooks', for example) to trigger the write to the second system. If you are on a completely closed SaaS platform with no API and no ability to customise, this pattern will be difficult or impossible to implement.
The second major consideration is monitoring and data reconciliation. A dual-write system creates a new risk: data drift. A subtle bug in the synchronisation logic could cause the two systems to slowly diverge over time. To mitigate this, robust systems are required. We build dashboards to monitor the health of the message queues and the success rate of the API calls. More importantly, we build automated reconciliation scripts that run daily, comparing critical data sets between the two platforms and flagging any discrepancies for investigation. This investment in observability is non-negotiable; it is the price of a de-risked launch.
What this looks like in practice
Run end to end, the pattern reshapes the calendar of a replatform. The legacy site keeps trading and keeps receiving normal change: bug fixes, merchandising, integration tweaks, the work the business expects from its digital team. In parallel, the new platform fills up with real production data through the dual write, day after day, under realistic load. Decisions that would normally be deferred to a tense launch week, search relevance tuning, checkout edge cases, ERP reconciliation, are exercised quietly for months on real volumes instead of synthetic test data.
By the time the team is ready to switch traffic, there is no migration left to do. The new platform has already processed the live order shape, the live customer object and the live catalogue updates. Launch becomes a traffic decision, not a data event: a staged DNS shift behind a rollback plan, watched on the same dashboards that have monitored the parallel run. That is the trade. You pay for it up front in architecture, observability and discipline. You get back a launch that does not require the business to stand still, and a platform that arrives warm.
