Why consolidation is different from a normal migration
Moving one system to a new platform is largely a question of copying what exists. Consolidating several systems into one is harder, because the systems usually disagree with each other. Each was probably set up locally, for local reasons, by people who made sensible but different choices.
The result is that consolidation involves design decisions, not just transfers. Someone has to decide whose way of working becomes the standard, and that is as much a governance question as a technical one.
Why organizations consolidate
Typical motivations include:
- Reducing the effort of supporting many tools.
- Getting consistent reporting across sites or units.
- Cutting duplicate licences and manual re-entry.
- Making it easier to apply the same access and security controls.
- Preparing for growth, or following an acquisition.
These benefits are possible, not guaranteed. A single system can also become a single point of failure, can be slower to change, and may fit no one group perfectly. Some organizations decide that a hybrid or federated arrangement suits them better, and it is reasonable to test that question before committing.
Challenge 1: Conflicting data
When separate systems hold similar information, the same real-world thing is often recorded several times and in different ways. Examples include:
- The same customer or supplier appearing in several systems under slightly different names.
- Different code lists for products, departments or statuses.
- Different date, currency or unit conventions.
- Fields that exist in one system and not in another.
- Conflicting values for the same item, with no clear record of which is correct.
Before merging, decide on a target data model and rules for resolving conflicts. This is where master data management practices apply, together with attention to common data quality issues. The mapping and cleansing steps are described in the data migration article in this cluster.
A useful habit is to name a data owner for each major type of record. Without one, duplicate and conflicting entries are usually resolved ad hoc, or not at all.
Challenge 2: Differing processes
Two sites may do the same job differently. One approves purchases above a certain value, another approves everything. One records returns immediately, another weekly. Neither is necessarily wrong.
Consolidating onto one system forces choices:
- Adopt one site’s process for everyone.
- Design a new standard process that is a compromise.
- Allow configured variations where there is a real reason, such as a legal requirement in one location.
Process standardization can bring consistency, but too much of it can remove useful local adaptations. It helps to ask which differences exist for a reason and which are simply historical. Work on multi-site operations and decision rights is relevant here, because the question of what to share and what to keep local is rarely purely technical.
Challenge 3: Informal workarounds
Local systems often have unofficial helpers around them: a spreadsheet used to fill a gap, a manual check done by one experienced person, a report built by hand each month. These rarely appear in documentation. If the consolidated system does not support them, the need does not disappear; it comes back as a new workaround. Part of the current state assessment should be to find them, and part of the design should be to decide whether to support or retire each one.
Challenge 4: Different integrations and dependencies
Each local system may connect to different upstream and downstream tools. Consolidation means rebuilding or replacing these interfaces and checking that every consumer of the data still gets what it needs. Missing one is a common cause of problems that only appear weeks after go-live, when an overlooked monthly report or feed fails.
Challenge 5: People and ownership
Local teams may have built and cared for their systems and may feel that something is being taken away. Concerns are often legitimate: slower local changes, loss of tailored features, uncertainty about roles. Tools such as stakeholder mapping, a change champions network and an honest account of what will get worse as well as better can help. Dismissing the concerns tends to increase change resistance.
Ownership also needs settling. Who owns the combined system, who approves changes, and how do local units request them? Clear system ownership roles and a way to channel local input help prevent the central system from being seen as a distant black box.
An approach that tends to work
- Inventory everything. List each system, its data, interfaces and workarounds.
- Compare them. Identify where data models, codes and processes differ.
- Agree the target. Decide on standards and where variation is allowed, with named decision makers.
- Pick a sequence. Consider migrating one unit first as a pilot, since lessons from the first unit often save effort in later ones. The big bang versus phased question is explored separately.
- Cleanse and map data. Agree rules for duplicates and conflicts before loading.
- Test with real users from each unit, not only from the unit most similar to the target design.
- Plan the retirement of each old system once its users have moved.
When consolidation may not fit
It may be worth pausing if the units have genuinely different regulatory needs, very different business models or little shared data. In those cases a shared standard for key data and reporting, with separate underlying systems, can give some of the benefits at lower risk. Consolidation is a means to an end, and the end is what should be judged.