Consolidating Fifteen Disconnected Systems Without Stopping the Business

What should you do first when you have fifteen or more systems to consolidate?

Triage by risk, not by annoyance and not by platform. The system everybody complains about is rarely the one most likely to hurt the business, and the first instinct, picking a target platform and drawing a migration plan onto it, commits you to an order before you know where the danger sits. A triage takes each system in turn and asks three questions that decide its place in the queue, then records a handful of facts that decide how it can move.

Do this as a short, evidence-based exercise with the people who run each system, not as a questionnaire. The output is one table, and it becomes the backbone of every later decision, including the decision to leave some systems alone.

Why is a big-bang cutover the wrong default for a growing business?

A big-bang cutover moves every system over one planned weekend. It is attractive on paper because there is no period of running two worlds, and it can be right for a single, well understood system with a clean data set. With fifteen or more systems it bets the business on every unknown having been found in advance, which is the one thing a programme of that size cannot guarantee.

A growing business adds a second problem: the target keeps moving. New products, new regions and new teams arrive during a long programme, so a design frozen for one cutover date is out of date on the day it goes live. Staged consolidation absorbs that change, because each phase is designed against the business as it is when that phase starts.

• Unknowns surface one at a time in a staged programme, and each one affects one capability rather than the whole operation.
• Rollback is realistic for one capability; for fifteen systems at once it rarely is.
• Users learn the new platform in manageable pieces instead of all at once during peak disruption.
• Value arrives early, which keeps sponsorship alive through a multi-year programme.
• The cost is real: for a period you run old and new together, with interfaces and reconciliation between them. The rest of this page is about keeping that cost under control.

How does the strangler approach move one capability at a time?

The strangler approach puts a stable interface in front of a capability, such as customer onboarding, service requests or contract renewals, then moves what sits behind that interface from the old system to the new one while callers keep using the same entry point. When nothing uses the old implementation any more, it is switched off. Repeat capability by capability until the legacy system has nothing left to do.

The interface can be an API, a set of Power Automate or Azure Functions endpoints, a shared form in a portal, or simply one agreed file or event contract. What matters is that it is owned, versioned and described in writing, so that users and other systems are insulated from which back end is doing the work this month.

• Pick capabilities, not systems. A legacy system usually does several things; move them separately, starting with the one with the fewest dependencies.
• Define the interface contract first: fields, keys, direction, volume, error behaviour and who owns it.
• Route a small, identifiable slice through the new implementation first, for example one region, one product line or new records only.
• Keep a switch that sends traffic back to the old implementation, and rehearse using it.
• Retire the old path explicitly once the new one has run a full business cycle, such as a billing period or a quarter end.
• Integrations around the legacy system need the same discipline; our guide to rationalising point-to-point integrations covers outbox, retry and idempotent consumers, so we do not repeat it here.

How do you stop data drift and dual-write conflicts during a phased migration?

Data drift is what happens when the same record is edited in two systems during the overlap and nobody decides which edit wins. It is the most common way staged programmes lose trust: the new system shows one address, the old one shows another, and users go back to the system they believe. The cause is almost always an application or integration writing the same entity into both systems, or a two-way sync with no owner.

The rule that prevents it is simple to state and hard to keep: in each phase, every entity has exactly one owning system. Only the owner accepts changes. Every other system receives a one-way copy, keyed on a shared identifier, and a reconciliation job compares them continuously. When a capability moves, ownership moves with it on a stated date. (This is a design rule, not the Microsoft dual-write feature, which links Dynamics 365 Finance and Operations apps to Dataverse. Solzet does not implement Finance and Operations.)

• Give every shared entity a stable key that both systems store, and use alternate keys in Dataverse so every load is an idempotent upsert that can be replayed safely.
• Block edits in the non-owning system where you can, by security role, form logic or removing the screen, rather than relying on instructions.
• Report reconciliation differences to a named owner every day, with an age on each open difference.
• Never allow a two-way sync of the same fields unless one system is explicitly the tie-breaker and the rule is written down.
• Matching duplicates across systems and choosing which value survives is set out in our post-merger CRM consolidation guide.

What compensating controls satisfy auditors while the migration is still in progress?

Auditors do not expect a multi-year programme to be finished before the next audit. They expect to see that you know where the risk sits during the overlap and that controls cover it. A compensating control is one that makes up for a control you cannot yet have, such as single-system access review or a single audit trail, while data and processes are split across old and new. Agree them with internal audit or compliance at the start of each phase, not after a finding.

• A system of record register: for each regulated entity, which system owns it in the current phase and from what date. This is the single document most audit questions start from.
• Reconciliation evidence: the daily comparison reports and the log of differences with their resolution, retained for the audit period.
• Access review across both systems for anyone who can reach regulated data, including service accounts used by migration and integration jobs.
• Audit history preserved: auditing turned on in Dataverse for the tables and columns that matter before data arrives, and the legacy audit trail kept readable after the system is frozen.
• Change control for the migration itself: each load, mapping change and ownership transfer approved, logged and linked to its reconciliation result.
• Frozen, restorable legacy copies with a documented retention period, so historical records can still be produced on request.
• Solzet builds the technical evidence; what your regulator requires comes from your compliance team, not from us.

How do you sequence the programme so each step pays for the next?

A multi-year consolidation loses its budget when the early phases only spend money. Sequence so that each phase retires something with a cost, a risk or a manual workload attached, and report that result before asking for the next phase. The order below is typical, not fixed; the triage table decides it for your estate.

When should you leave a system exactly where it is?

Consolidation is not a goal in itself. Some systems are cheaper and safer to keep, connected through a stable interface, than to move. Writing the criteria down early stops the programme from growing to include everything, and it gives sponsors an honest answer when they ask why a particular system is still running.

• It is supported, stable and does one specialised job well, such as a payroll, ERP, warehouse or engineering system whose domain the target platform was never meant to cover.
• Its data is used by few people and exchanged with the core through a simple, reliable interface.
• Moving it would mean rebuilding specialised logic that gives no advantage when rebuilt.
• It is due for retirement anyway, for example a product line being wound down, and can simply be frozen when the time comes.
• The regulatory or contractual cost of moving its data exceeds the benefit of consolidating it.
• Solzet integrates the core platform with finance and ERP systems but does not implement or replace them; Dynamics 365 Finance, Business Central, NAV and Finance and Operations stay outside our scope.

Should the target be Dataverse or a custom-built platform?

This guide's address mentions Dataverse because it is the most common consolidation target we are asked about, but the honest answer is that it depends, and the triage and strangler method above work the same for either. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

Dataverse, with Dynamics 365 or Power Platform apps built on it, fits when most of the consolidated capabilities are customer, service, sales or case work, when Microsoft 365 and Teams matter, and when per-user Microsoft licensing suits the number of people who touch the data. A custom-built platform on React, Node.js, PostgreSQL or .NET fits when many occasional users make per-user licensing hard to justify, when hosting or data residency rules exclude the Microsoft cloud, or when the consolidated logic is the business differentiator and you want to own the code outright. Some estates end with both: Dataverse for the customer-facing core and a custom service for a specialised capability, joined by the same stable interfaces the strangler approach created.

What if a system has no original developers, a merger behind it, or manual processes around it?

Large estates usually contain all three, and each has its own method on this site, so this guide points to them rather than repeating them.

• A system nobody can explain, whose developers have gone: prove restore, reverse-engineer the data model and rules from historical outputs, and run in parallel, as set out in legacy migration with no original developers.
• Two CRMs brought together by an acquisition, especially with a reporting deadline: post-merger CRM consolidation.
• Manual processes and spreadsheets filling the gaps between systems: score and sequence them with the process automation portfolio roadmap.
• The data load itself, including field mapping, created dates, attachments, tooling and validation: the data migration guide, whose mechanics apply to most source systems, not only Salesforce.
• Fragile integrations holding the estate together: point-to-point integration rationalisation.
• Customer identity scattered across departmental spreadsheets rather than systems: consolidating customer data into a single source of truth.

How does Solzet run a staged consolidation programme?

We start with a fixed scope assessment: the inventory and risk-first triage, the capability map, the system of record register, a recommended target (Dataverse, custom or a mix, with the reasons) and a wave plan whose first two waves are costed in detail. Nothing is migrated until that plan is agreed with your business owners and, where regulated data is involved, your compliance team.

Delivery then runs wave by wave: stable interfaces first, one capability at a time behind them, reconciliation running from day one, and a written result at the end of each wave before the next is committed. Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement, Power Platform and custom CRM development, directly or white-label for Microsoft partners. We integrate with ERP and finance systems but do not implement Dynamics 365 Finance, Business Central, NAV or Finance and Operations.