M. Pact Advisory. From insights to impact. Fast.
All research

Technology roadmaps · Finance systems · Practical guide · Free

Decide whether to consolidate your ERP systems

Take the two systems the business is arguing about, start from the result the business needs, test what each route can deliver and what each cannot, separate the differences that must stay from the ones that accumulated, put both routes and their sequence on one cost timeline, and ask for one decision with the trigger that reopens it.

What you finish with: One consolidation decision with the business result it serves, the differences that stay, the routes and their sequence costed on one timeline, the dependency outside the team's control, the decision requested with its conditions, and the condition that reopens it.

Download PDFGo to the working record

ARCHITECTURE / CONTINUITY

Compare routes before choosing the system.

Business need

The capability and problem the decision must address.

Whole-life economics

Transition, running cost and existing commitments.

Ability to deliver

Dependencies, capacity, controls and a safe exit.

Keep a working bridge until its replacement works. Name the condition that reopens the choice.

Use the same scope and cost period for the routes being compared.
Read the diagram

Business need: The capability and problem the decision must address.; Whole-life economics: Transition, running cost and existing commitments.; Ability to deliver: Dependencies, capacity, controls and a safe exit.. Keep a working bridge until its replacement works. Name the condition that reopens the choice.

01

Start with the result the business needs, not the number of systems

Two ERP instances are not a problem in themselves, and one instance is not a result. Write the result the business needs in the words the leadership team uses, with its measure and its date: a group close of a stated length, one customer or product master, a margin view produced without a manual step, one control environment. Then test each route against it: what the route can deliver, what it cannot in the design as scoped, and the evidence that would show it delivered.

A single system does not produce a shorter close by itself; a shared close calendar, a standard close checklist and intercompany handled inside the system do, and those can be designed on either route. If no result depends on the decision, consolidation is a cost question and the guide on removing technology costs is the better tool.

02

Separate the differences that must stay from the ones that accumulated

List the processes where the two systems work differently, starting with the ones that affect the decision rather than a complete inventory. For each, ask what would break if it were standardized: a regulation, a customer's contractual requirement, a market practice the business competes on, a control the auditor relies on. Those are the questions to start with, not a complete list of legitimate reasons. A difference whose requirement is not yet known stays unresolved with an owner and a date; it is not clutter until someone has shown that nothing depends on it.

Everything shown to have no requirement behind it is an accumulated difference: a configuration someone made, a report someone liked, a workaround for a problem that no longer exists. Preserve the requirement, not every inherited configuration.

03

Put the routes and their sequence on one cost timeline

Cost every route the decision actually proposes on the same lines: one-time cost including data cleansing, the customizations to retire or rebuild, training and the dual-running period; recurring cost added, from the date it starts; cost that ends, with its notice period and the date it actually leaves the ledger; capacity released, counted separately from cash. If the decision is one route now and another later, cost the sequence as a whole, including the bridge's running cost until it is retired and what of it is reused or written off.

Put every figure on one timeline from the decision date, because a saving that starts in month twenty-two and a license that starts in month nineteen are not the same year. Then put the business result beside the cost with the date each route delivers it and the date the business accepts it in use. Name the dependency the team does not control: the other program that needs the same people, the data owner in another domain, the vendor's own roadmap.

04

Ask for one decision and set the trigger that reopens it

State the decision in one sentence: which route or sequence, what it costs on the timeline, who approves it, and what result it serves. Where a consequence is not yet costed, make the decision conditional on that figure rather than treating the unknown as zero. State the alternative honestly, including keeping both systems as they are. Set the trigger that reopens the decision: a vendor notice, a result not accepted in use by a date, the dependency slipping. Say what happens if it fires: the option is reconsidered and continuity is preserved, so a working bridge is not stopped until its replacement works.

Name the roles as they are in the organization: who approves, who owns the result, who owns delivery and run cost, who owns the controls that move and tells the auditor through the ordinary audit plan.

Example decision

Two instances after an acquisition

A manufacturing group runs its main ERP for 900 users and, since an acquisition two years ago, a second ERP from a different vendor for the acquired unit's 300 users. In October 2026 the finance leader wants a five-day group close by December 2028 instead of the current nine days, and a product-line margin view that does not need the group accountant's manual month-end reconciliation between the two systems. The acquired unit's leadership wants to keep the way it prices and costs its projects.

The result the business needs:

A five-day group close, evidenced by two consecutive month-end closes signed off at five working days or fewer, and a product-line margin view accepted for use by the finance leader without a parallel spreadsheet; both by December 2028, owned by the finance leader.

The close result depends on one close calendar, one close checklist and intercompany handled in the system, not on the number of systems; the manual reconciliation it removes is replaced, under Route A, by matched control totals from the migrated sub-ledgers to the group ledger, reviewed exceptions and the group controller's sign-off before the parallel spreadsheet retires, and under Route B by an automated reconciliation report with the same review and sign-off.

Each is a requirement to demonstrate, not something delivered by choosing a system.

Differences that stay:

Of the processes that affect this decision, three must stay: a regulated pricing rule in the acquired unit's market, a customer-mandated invoice and order format for its largest account, and project-based costing that the unit's contracts depend on. Eleven have been shown to have no requirement behind them and are accumulated.

Two are unresolved, with the unit's commercial director to confirm by the end of November 2026 whether a customer or regulator depends on them; the October decision carries them as requirements to keep until then. The commercial director of the acquired unit owns the three that stay.

Compare the routes

What changes

Route A: consolidate:

Move the acquired unit onto the main ERP.

Route B: connect:

Keep both ERP systems. Add integration and a consolidated reporting layer.

One-time cost

Route A: consolidate:

$2,400,000 total.

Migration and data cleansing: $1,500,000.

Retire or rebuild 22 customizations: $500,000.

Training and four months of staff time running both processes: $400,000. The second ERP license during its notice period is separate.

Route B: connect:

$350,000 for integration and the reporting layer.

Recurring cost added

Route A: consolidate:

$180,000 a year from go-live: 300 users at $600 each.

Route B: connect:

$90,000 a year for the reporting layer.

Existing cost that ends

Route A: consolidate:

$520,000 a year in the second ERP license and support, ending three months after go-live under its notice terms.

Route B: connect:

None.

Staff capacity released

Route A: consolidate:

One full-time system-support role in the acquired unit. Count capacity separately from cash savings.

Route B: connect:

None.

Product-line margin view

Route A: consolidate:

Available at go-live. Accepted when the finance leader signs a month’s product-line margin from the system without a parallel spreadsheet.

Route B: connect:

Available six months after approval. The finance leader must accept it in use.

Five-day group close

Route A: consolidate:

The design must include the common close calendar, checklist and intercompany controls. Accept the result only after two consecutive closes signed off at five working days or fewer.

Route B: connect:

Not delivered in this scope. The unit’s close process and calendar stay unchanged; a shared close calendar has not been designed, tested or costed.

Delivery dependency

Route A: consolidate:

Needs the group data team for 18 months. It cannot run alongside the warehouse replacement.

Route B: connect:

Provides the margin view while the warehouse replacement proceeds. Subsequent Route A work waits for the data team.

The shared dependency:

The warehouse management replacement is scheduled to start in April 2027 and needs the same data team for twelve months, to March 2028. Route A and the warehouse replacement cannot run together; one of them moves.

Compare timing and total cost

Start and go-live

A first:

A starts October 2026. Go-live: April 2028, month 19.

B now, then A:

B goes live April 2027, month 7. A starts April 2028 and goes live October 2029, month 37.

Margin view

A first:

Available April 2028. Acceptance requires the finance leader’s sign-off on a month’s results without the parallel spreadsheet.

B now, then A:

Available April 2027; planned acceptance by July 2027. The margin view is available 12 months earlier.

Five-day close target

A first:

By December 2028, after two consecutive five-day closes are signed off.

B now, then A:

Move the target from December 2028 to June 2030, after two consecutive five-day closes are signed off.

Warehouse replacement

A first:

Moves from April 2027 to May 2028: a 13-month delay. Operations has not yet stated its cost.

B now, then A:

Keeps its April 2027 start and uses the data team through March 2028.

One-time outlay

A first:

$2,400,000.

B now, then A:

$350,000 for B plus $2,400,000 for A: $2,750,000.

Main ERP license added

A first:

April 2028 through September 2031: 42 months × $15,000 = $630,000.

B now, then A:

October 2029 through September 2031: 24 months × $15,000 = $360,000.

Reporting layer cost

A first:

None.

B now, then A:

April 2027 through December 2029: 33 months × $7,500 = $247,500. Retire the layer only after A’s margin view is accepted, planned for December 2029.

Old ERP cost avoided

A first:

From July 2028, month 22: 39 months × ($520,000 ÷ 12) = $1,690,000.

B now, then A:

From January 2030, month 40: 21 months × ($520,000 ÷ 12) = $910,000.

Net outlay over 60 months

A first:

$2,400,000 + $630,000 − $1,690,000 = $1,340,000.

B now, then A:

$2,750,000 + $247,500 + $360,000 − $910,000 = $2,447,500.

What is still unknown

A first:

Cost and business consequence of delaying the warehouse replacement, from the operations director.

B now, then A:

Value of receiving the margin view earlier, from the finance leader. Reuse of B’s data mappings in A’s migration, from the applications lead. Each extra month before the layer can retire adds $7,500, subject to its exit terms.

Decision window: October 2026 through September 2031, 60 months. Figures compare changes in cash outlay over that common window. Old ERP cost avoided uses the exact annual cost divided by 12, without rounding the monthly figure first. Unknown costs and benefits are not counted as zero.

The price of the sequence:

B now, then A costs $1,107,500 more over the 60-month window: $2,447,500 less $1,340,000. It brings the margin view forward by 12 months and preserves the warehouse replacement’s date, while moving the five-day close target to June 2030.

That comparison still needs the value of the earlier margin view, the consequence of delaying the warehouse work, and any confirmed data-mapping reuse. Each extra month of the reporting layer adds $7,500, subject to its exit terms.

Decision requested:

At the October 2026 investment review, approve Route B, 350,000 one time and 90,000 a year, to deliver the margin view by April 2027 and accepted in use by July 2027, and schedule Route A to start in April 2028 with the five-day close target moved from December 2028 to June 2030 (two five-day closes signed by then).

The chief financial officer chooses the trade-off on four things put in front of the review together: the sequence premium confirmed net of reuse, from the applications lead; the consequence of moving the warehouse replacement by thirteen months, from the operations director; the value of the margin view arriving in 2027 rather than 2028, from the finance leader; and explicit acceptance of the later close date.

Where a benefit or a cost is not yet known, it stays unknown at the review and is not treated as zero. The finance leader owns the result; the applications lead owns delivery and the run cost; the group controller owns the reconciliation control and the audit plan.

The alternative, stated honestly: approve Route A in October 2026, move the warehouse replacement to May 2028, plan go-live for April 2028 and accept the five-day close result only after two consecutive month-end closes are signed off at five working days or fewer, by December 2028.

Trigger:

The decision reopens if the second ERP's vendor announces end of support for the unit's version, if the finance leader has not accepted the margin view in use by the end of August 2027, or if the warehouse replacement's start slips past July 2027.

If it fires, the finance leader brings the timeline back to the same investment review with the figures updated; the reporting layer keeps running until whichever route replaces it is accepted in use.

Keep the next decision clear.

Copy this record into the document you already use with your team. Give an unanswered question an owner and a next action.

Your working record

System consolidation decision

Result the business needs (measure, acceptance evidence, date, owner):
To complete
What each route delivers, what it cannot in this scope, and why:
To complete
Differences that must stay (regulation, customer, market, control), owner of each:
To complete
Differences unresolved, owner and date to confirm:
To complete
Accumulated differences (count) and what removes them:
To complete
Route A on the timeline (one-time, recurring added from when, cost ending when, capacity released, result date):
To complete
Route B on the timeline (one-time, recurring added from when, cost ending when, capacity released, result date):
To complete
Sequence, if one route bridges to another (bridge running cost, reuse or write-off, premium over the direct route):
To complete
Dependency outside the team's control (program, owner, date, cost of moving it):
To complete
Decision requested (route or sequence, cost on the timeline, who approves, result served):
To complete
Figures still needed before approval, and who brings them:
To complete
Alternative stated honestly:
To complete
Result owner, delivery and run-cost owner, controls owner:
To complete
Trigger (vendor notice, result not accepted by date, dependency slip) and what continues if it fires:
To complete

Next: Find technology costs you can remove If no business result depends on the decision, consolidation is a cost question, and that guide is the tool.