When enterprise software transformations are parked behind massive ERP programs, steering committees often default to sequencing procurement initiatives after completion because it feels like the low-risk choice. However, waiting on a moving timeline means planning against a date nobody controls, especially given that Gartner predicts over 70% of recently implemented ERP initiatives will fail to fully meet their original business goals by 2027.
If your organization is facing a long migration, deciding whether a procurement wait for ERP go-live policy makes sense requires testing core assumptions about data dependencies and timeline stability.
In this article, we explore a three-question test for CPOs to determine whether to start transforming procurement now or remain parked behind the ERP program.
A three-question test for procurement leaders whose transformation has been parked behind an ERP program, and why the answer is usually no.
TL;DR
- Usually not. Waiting makes sense only if your ERP program can name a stable go-live date for its final business unit.
- Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals.
- BCG Platinion observes “transformation cycles taking place every 5 to 7 years, and changes in management causing significant delays.”
- Most of procurement depends on ERP data, not on ERP go-live. A regular copy of that data is enough to start.
- Only the move to the new ERP itself has to wait for go-live.
- Get the three-stage plan and readiness scorecard in the ebook: Procurement Doesn’t Have to Wait for the ERP
Usually not. Unless your ERP program can name a stable go-live date for its final business unit, waiting means planning procurement against a date that keeps moving. The better question is which parts of procurement depend on the ERP at all. Most can start on a regular copy of ERP data, and only the move to the new ERP itself has to wait for go-live. This article gives CPOs and procurement leaders at large enterprises a three-question test to decide.
Why is “after go-live” the default answer?
Because it sounds responsible. The ERP program is the largest change in the building, IT capacity is committed to it, and nobody wants to build a procurement integration twice. Sequencing procurement after go-live looks like the low-risk choice, and in a steering committee it is the easiest decision to defend.
The problem is not the logic. It is the two assumptions underneath it: that go-live is a fixed point you can plan around, and that procurement cannot do anything useful until the ERP is finished. Both deserve a test before they harden into a multi-year plan.
How reliable is the go-live date you are planning against?
Less reliable than the plan suggests.
Business goals and dates are not the same thing, but they tend to slip together. Duration is just as uncertain.
Large programs also go live in waves. A go-live date for the first business unit is not a go-live date for the last one, and procurement usually needs the last.
This is not a criticism of ERP teams. Large programs run into business change, complexity and redesign decisions that nobody can schedule in advance. The point is narrower: a plan that depends on a date nobody controls is a plan procurement does not control either.
What happens to a waiting plan when leadership changes?
It loses its sponsor.
Writing about large enterprises in the Nordics, BCG Platinion observes that “with transformation cycles taking place every 5 to 7 years, and changes in management causing significant delays, windows of opportunity for modernization are small and close fast.”
A wait agreed this year is a commitment the next CPO, CIO or CFO inherits. If the ERP timeline slips into a new leadership cycle, procurement’s plan gets reopened from zero, often by people who were not in the room when “after go-live” was agreed.
What is the decision rule?
Ask three questions, in this order.
- Can the program give you a written go-live date for the final business unit, live and stable, that has not moved in the last year? If not, you are planning against a direction, not a deadline. Start now.
- Does what you want to run need a live ERP connection, or only a regular copy of ERP data? Intake, sourcing, contracts, supplier onboarding and spend visibility can run on a copy. If a copy is enough, start now.
- Is the ERP program also replacing the platform that connects the ERP to other tools? If it is, still start now, and plan to connect to the new platform rather than the one being retired, so nothing is built twice.
Waiting is the right answer in a narrow case: a near, fixed date for the final business unit, and a scope that genuinely needs live ERP transactions from day one. Figure 1 shows the test.
Each verdict means something specific. Start now means beginning on a copy of ERP data, with a clear boundary on what goes back to the ERP and how. Start now and connect later adds one design decision: the live connection is built on the target platform. Wait means fixing a date to revisit the decision, not an open-ended hold.
Figure 1: The three-question test. Most paths lead to starting now.
Which parts of procurement actually depend on the ERP?
Fewer than the “after go-live” plan assumes. The process can run independently; the data cannot. That turns one large dependency into three smaller ones:
- Start now, on a regular copy of ERP data.
- Connect, once the IT program is ready, on the platform it is moving to.
- Move with the ERP at go-live, planned into the program’s testing from the start.
Only the third waits for go-live. Each stage needs something specific from the ERP and from your teams, and the honest version includes some rework when the new ERP arrives. That detail, stage by stage, is what the ebook is for.
What does starting now look like on day one?
It starts at the front door. With Merlin Intake, requests arrive through one conversational channel and are coded against the same cost centers and accounts the ERP checks, so data is right from the first request. In one documented Zycus deployment, more than 1,000 regular users and 4,500 suppliers run intake through that single front door.
Sourcing, contracts and supplier onboarding follow on the Merlin Agentic Platform, which runs alongside the ERP rather than inside it. Built-in beats bolt-on here: the request captured at the front door is the same record sourcing and contracting work from, with no handoff between separate tools. That is what Intake to Outcomes means in practice: value starts at the request, not at ERP go-live.
Two things change for the team straight away. Requests stop arriving by email, and approved requests reach the ERP by file or by hand until the live connection is in place.
What should you ask your ERP program before you decide?
Ask for the date the final business unit will be live and stable, and what that date was a year ago. Ask whether the integration platform is changing. Ask who will own the data procurement needs in the meantime. The answers decide your verdict, and they usually point the same way.
If the answers are vague, that is also an answer. A program that cannot name its own end date is not a reason for procurement to stand still.
Forcing a procurement wait for ERP go-live decision can stall digital modernization for years, leaving your teams trapped behind multi-year IT timelines and shifting enterprise schedules. By leveraging regular copies of ERP reference data and deploying solutions like Merlin Intake ahead of live connections, CPOs can modernize source-to-contract workflows immediately without disrupting core financial systems.
The ebook turns those questions into a readiness scorecard and walks through each stage: what it needs from the ERP, who does what, and what changes at go-live.
Procurement Doesn’t Have to Wait for the ERP. A three-stage plan to start now and connect as your ERP program moves. Download the ebook →
Ready to start your procurement transformation without waiting for IT bottlenecks? Request a demo to explore the three-stage readiness scorecard and start your journey today.
Frequently asked questions
1. Can procurement software be implemented before an ERP migration finishes?
Yes. Most procurement capabilities, including intake, sourcing, contract management, supplier onboarding and spend visibility, run on a regular copy of ERP reference data rather than a live connection. Approved requests reach the ERP by file or manual entry until a live connection is in place. Only the move to the new ERP itself has to be planned around go-live.
2. Will we have to build the procurement integration twice?
Not if you connect to the right platform. Many ERP programs also replace the middleware that links the ERP to other tools. Connecting to the platform the program is moving to, rather than the one being retired, avoids building twice. Some rework still happens at go-live, mainly where supplier records and finance structures change, so plan it into the program’s testing.
3. What ERP data does procurement need to start?
Mainly reference data: legal entities, purchasing units, cost centers, GL accounts and categories, plus accounts payable and purchase order history for spend analysis. This data changes slowly, so a scheduled extract is enough. The extract is still real work for your data team, but it is not a project on the ERP program’s critical path.
4. How does Merlin Intake work before the ERP is live?
Merlin Intake gives every request one conversational front door and codes it against the same cost centers and accounts the ERP validates. It runs on a copy of ERP reference data, so it does not depend on go-live. Approved requests then reach the ERP by file or manual entry until the live connection is in place.
5. When should procurement wait for the ERP?
Waiting is reasonable in a narrow case: the program has a near, fixed go-live date for its final business unit, and the procurement scope genuinely needs live ERP transactions from day one. If the date has moved in the last year, or a copy of ERP data is enough, starting now is usually the better decision.
6. What has to be reworked when the new ERP goes live?
Some things change regardless of when procurement starts. Supplier records move to the new ERP’s format and supplier numbers may change. Entities, accounts and categories change if the program redesigns them, and approval rules follow. The technical connection is updated on both sides. The size of this rework depends on how far the ERP program redesigns the business.
7. Who owns procurement data during an ERP migration?
The ERP stays the system of record for suppliers, purchase orders, receipts and payment. Procurement tools read from it and send approved requests, new suppliers and awards back. Agree early who produces the data extracts, how often they refresh, and who owns supplier records, so nothing is created twice during the migration.
8. Does starting procurement early slow down the ERP program?
It should not, if the boundaries are clear. Stage one needs a data extract, not program resources, and the live connection waits until the program is ready. Procurement going first can also hand the program cleaner supplier and category data before conversion, though no study yet measures how much that reduces migration risk.
