On this page
- Ownership before the plan
- What must be true at go-live
- Freeze the right scope
- Migration is a workstream
- What data must move
- Clean before you migrate
- Rehearse the migration
- Reconcile, not just count
- Test the whole chain
- UAT belongs to the business
- Test the exceptions
- UAT issue severity
- Test integration failures
- Training is not readiness
- Train the support network
- Build the cutover plan
- Practice the cutover
- Go / no-go, explicitly
- Rollback criteria
- Parallel running
- Go-live starts stabilisation
- Keep the project team
- When is it actually stable?
- Phase 2
- See the implementation plan
- Implementation red flags
- Go-live readiness gate
- How exactllyERP fits
- Readiness checklist
- Go deeper
The useful question is therefore not “When can the software go live?” It is “What must be true before the business can safely operate in it?”
The implementation is the controlled transition from the way the business operates today to a new system of record that people can trust and operate reliably.
That transition includes:
- governance;
- scope decisions;
- process configuration;
- master data;
- historical and opening data;
- integrations;
- testing;
- user readiness;
- cutover;
- support;
- stabilisation.
A technically working ERP can still be an unsuccessful implementation if the opening balances are wrong, warehouse users keep a parallel spreadsheet, an integration fails during dispatch, or nobody knows who owns an issue after go-live.
Start with ownership before the project plan
A vendor can provide an implementation methodology.
The business still has to own the implementation.
That ownership should be visible before kickoff.
Executive sponsor
The sponsor owns the business outcome.
Typical responsibilities include:
- resolving cross-functional conflicts;
- protecting the project team’s capacity;
- making decisions that departments cannot resolve themselves;
- controlling major scope changes;
- confirming whether the organisation is ready to cross major gates.
The sponsor should not become the person approving every screen.
But the project should have somewhere to escalate decisions that affect the whole business.
ERP project champion
The project champion turns executive intent into daily coordination.
The role may include:
- tracking decisions;
- coordinating functional owners;
- maintaining scope;
- escalating blocked issues;
- ensuring testing and data owners deliver their work;
- keeping the business and implementation partner aligned.
This role cannot be performed effectively by someone who has neither authority nor time.
Functional owners
Finance, sales, procurement, warehouse, production, quality and other in-scope functions should own whether their processes are ready.
The implementation partner
Knows the ERP.
The functional owner
Knows whether the configured process can run the business.
Both are required.
Define what must be true at go-live
Before the project becomes a calendar of tasks, define its acceptance conditions.
For example:
- opening financial balances reconcile;
- stock opening quantities and values are accepted;
- critical masters are approved;
- in-scope business processes work end to end;
- integrations required on Day 1 are operational;
- users have the correct roles;
- critical reports are available;
- cutover migration has been rehearsed;
- support ownership is active;
- blocking UAT issues are resolved or formally accepted.
These are not
Dates.
They are
Evidence.
A project can reach the planned Friday evening without being ready to go live.
The date should not substitute for the evidence.
Freeze the right scope, not every future idea
ERP projects often discover legitimate improvement opportunities during implementation.
That does not mean all of them belong before the first go-live.
Separate:
Required for Day 1
Without it, the business cannot safely operate the agreed scope.
Required soon after go-live
Important, but does not block the transition.
Future improvement
Useful enhancement or optimisation that can be governed after the core operation is stable.
This prevents the project from becoming an endless attempt to perfect the future system before anyone uses it.
Do not use “Phase 2” as a convenient place to hide a genuine Day-1 requirement. The decision should be based on operational necessity.
Treat data migration as its own workstream
Data migration is not simply:
export old data → import new data.
It requires decisions about:
- what data is in scope;
- data ownership;
- cleansing;
- transformation;
- mapping;
- validation;
- cutover timing;
- reconciliation.
The business owns
Whether the migrated data is correct.
The vendor or implementation team
May execute the migration.
Those are not the same responsibility.
Decide what data really needs to move
“Move all history” sounds safe.
It may not be necessary.
Divide legacy information into useful groups.
Configuration data
Information that helps configure the new ERP. Examples may include:
- tax codes;
- currencies;
- parameters;
- numbering;
- organisational structure.
Master data
Information repeatedly used by transactions. Examples:
- customers;
- suppliers;
- items;
- chart of accounts;
- BOMs;
- locations.
Opening balances and stock
The financial and inventory position from which the new system begins.
Open transactions
Transactions still operationally active at cutover. Examples may include:
- open sales orders;
- open purchase orders;
- outstanding receivables/payables;
- active production/work orders.
Historical transactions
Older completed transactions.
Some organisations need extensive historical data inside the new ERP.
Others can retain older information in a secure accessible archive and migrate only what the business genuinely needs.
Ask:
What must users transact on, report from, compare against or audit inside the new ERP?
That gives the history decision a business reason.
Clean before you migrate
A new ERP does not make old data correct.
Before migration, look for issues such as:
- duplicate customers or suppliers;
- obsolete items;
- inconsistent units of measure;
- missing tax information;
- invalid addresses;
- incorrect account mappings;
- duplicate codes;
- inactive locations;
- old open orders that are no longer genuinely open.
Do not make the migration script responsible for deciding business truth.
Each important master should have a named business owner.
That owner decides:
Is this record valid enough to become part of the new system of record?
Rehearse migration before cutover
Do not let the first complete migration happen during go-live.
A migration rehearsal should help establish:
- how long extraction takes;
- how long transformation takes;
- how long loading takes;
- which records fail;
- which mappings are incomplete;
- whether volumes fit the cutover window;
- which reconciliation steps are required.
The last rehearsal should resemble the real cutover as closely as practical.
Reconcile the result, not just the record count
“10,000 records exported; 10,000 imported” is useful.
It is not sufficient.
Data can have the correct count and still be wrong.
Validation may need to include:
Counts
Did the expected number of records move?
Control totals
Do relevant financial or quantity totals reconcile?
Balances
Do opening ledgers, receivables, payables, stock and other critical balances match the agreed source position?
Relationships
Do customers, orders, items, batches, BOMs or other linked records still connect correctly?
Business sampling
Can functional owners inspect representative records and confirm that they mean the same thing in the new ERP?
The exact controls depend on the data.
But somebody must define what “migration accepted” means before the final load.
Test the complete operating chain
ERP testing should not be organised only screen by screen.
An order does not end when the order-entry screen saves successfully.
The workflow may continue through:
Order chain- order
- credit control
- stock allocation
- picking
- dispatch
- invoicing
- receivable
- reporting
A production process may continue through:
Production chain- demand
- material planning
- work order
- issue
- production
- quality
- finished stock
- costing
Test the chain.
This is where configuration, data, security, integration and process design meet.
UAT belongs to the business
User Acceptance Testing is not the vendor demonstrating the system again.
The business users should operate the configured solution and decide whether it supports the agreed business process.
A useful UAT group includes people who actually perform or own the workflow.
For example:
The project manager should coordinate UAT.
The business should accept it.
Test exceptions, not only the happy path
A normal transaction often proves very little.
The important implementation risks are frequently in exceptions.
For example:
What happens when part of a purchase receipt fails inspection?
What happens when the customer exceeds the credit limit?
What happens when stock is transferred between two locations and one quantity is short?
What happens when a production order yields less than expected?
What happens when an integration is temporarily unavailable?
What happens when a transaction needs reversal or correction?
That is closer to the real business than a scripted perfect day.
Separate UAT issues by severity
Not every UAT issue should have the same effect on go-live.
A useful classification might be:
Blocking
The business cannot safely run a critical in-scope process.
Significant but manageable
The process works, but an issue requires a controlled workaround or early fix.
Enhancement
The business can operate, but a future improvement would be valuable.
The exact terminology is not important.
The governance is.
Before go-live, every unresolved issue should have:
- an owner;
- agreed severity;
- action;
- target resolution or accepted workaround;
- business acceptance where it remains open.
A project should not go live merely because the issue list is long and everyone is tired of testing.
Test integrations as failures as well as successes
An integration is not ready merely because one successful transaction moved.
Test:
- expected transaction flow;
- duplicate handling;
- failed messages;
- invalid data;
- delayed response;
- system outage;
- recovery/reprocessing;
- monitoring;
- user communication.
Do not confuse training with readiness
Training completion is
A project milestone.
User readiness is
An operating condition.
A user may attend a training session and still not be ready to perform their job in the new ERP.
Train people around the work they actually perform.
For example:
Warehouse user
Receive, pick, transfer, count, dispatch.Accounts user
Post, reconcile, correct, close, report.Production user
Release, issue, report output, record rejection/rework.Manager
Approve, review exceptions, use operational reports.People do not need equal depth in every module.
They need enough competence to run their role.
Train the support network too
Go-live creates two kinds of questions:
How do I do this?
Something is wrong. Who owns it?
Before launch, define:
- first point of contact;
- functional champions;
- internal IT/support;
- vendor/implementation contact;
- escalation route;
- issue logging method.
The support organisation should not first discover the ERP on go-live morning.
Build the cutover plan backwards from Day 1
Cutover is the controlled movement from the legacy operating environment into production use of the new ERP.
Start by asking:
What must be correct when users begin work in the new system?
Then work backwards.
A cutover plan may contain:
final legacy transaction cutoff
final data extraction
transformation/load
reconciliation
configuration promotion
user/security activation
integration activation
opening balance validation
stock validation
smoke tests
communication
business sign-off
go/no-go decision
For every activity, identify:
Practice the cutover before doing it for real
A cutover plan that has never been executed is still a theory.
Run a mock cutover or dress rehearsal.
Use, as far as practical:
- the real migration process;
- realistic volumes;
- actual responsible people;
- the intended sequence;
- integration steps;
- validation checks;
- timing assumptions.
The rehearsal should answer:
Can the team complete the transition within the operational window?
Which steps take longer than expected?
Which dependencies were missing?
Who cannot complete their assigned task?
Which checks are ambiguous?
Then update the plan.
Make the go/no-go decision explicit
Go-live should not happen through momentum.
Before the cutover begins, define what would cause management to say:
GO
The critical acceptance conditions are satisfied.
CONDITIONAL GO
A limited set of known issues remains, but the business has explicitly accepted the operational risk and workaround.
NO-GO
A critical process, data set, integration, control or support dependency is not ready.
The exact governance structure will differ by organisation.
But someone must have authority to say:
We are not ready.
A date in the calendar cannot make that decision.
Know your rollback criteria
Rollback should not be improvised in the middle of a cutover.
Before go-live, decide:
- which failures would trigger rollback;
- who can call it;
- the last point at which rollback remains feasible;
- how data entered during the transition is handled;
- how users will be informed;
- how the legacy environment will be restored to operational use.
The objective is not to expect failure.
It is to avoid debating fundamental continuity decisions during an incident.
Parallel running is a transition choice, not a default
Some organisations run legacy and new systems in parallel for a transition period.
Others use a controlled hard cutover.
Neither model is automatically correct for every ERP rollout.
Parallel running
May provide additional comparison and confidence.
It can also create:
- duplicate work;
- conflicting systems of record;
- reconciliation burden;
- temptation to keep using the old workflow.
A hard cutover
Creates clearer ownership of the new ERP.
It also requires stronger pre-go-live readiness.
The decision should depend on:
- business risk;
- type of process;
- ability to reconcile systems;
- operational continuity;
- compliance requirements;
- confidence from rehearsals and UAT.
Do not keep two operational systems alive indefinitely merely because nobody wants to decide which one is authoritative.
Go-live is the start of stabilisation
Go-live changes the type of work.
Before go-live, the question is
Can the system operate the business?
Immediately after go-live, the question becomes
Is the business actually operating reliably in it?
The early support period should focus on:
- blocking transaction issues;
- data corrections;
- integration failures;
- user/security problems;
- incorrect configuration;
- reporting defects;
- process misunderstanding;
- user support.
Do not treat every enhancement request as a production incident.
The team needs a way to separate:
Break/fix
Something needed for agreed operations does not work.
Adoption/support
A user needs help performing the new process.
Enhancement
The system works, but the business wants it improved.
Otherwise every improvement idea competes with operational stability.
Do not dismantle the project team on go-live day
The people who know:
- why the configuration was designed that way;
- how data was mapped;
- which UAT decisions were made;
- which integrations have special handling;
- which issues were accepted,
are most valuable immediately after launch.
Plan the transition from implementation to support.
Do not simply close the project and send every issue to a generic helpdesk the next morning.
When is the ERP actually stable?
There is no universal number of days after which every ERP is “stabilised.”
Use evidence.
A stable implementation might mean:
- critical transactions run reliably;
- opening and ongoing balances reconcile;
- integrations operate without unresolved critical failures;
- users can perform core roles;
- support tickets are controlled and declining in severity;
- management reports are being generated from ERP;
- legacy workarounds are no longer required for the agreed scope;
- responsibility has transferred from project mode into normal support.
The exact exit criteria should be agreed before go-live.
Otherwise “stabilisation complete” becomes simply another calendar date.
Phase 2 should begin after the core is controlled
A live ERP will immediately generate ideas.
Good.
Capture them.
But distinguish optimisation from stabilisation.
Starting large new enhancements while:
- users still struggle with core workflows;
- migration balances are unresolved;
- integrations remain unstable;
- support ownership is unclear,
makes it harder to tell whether a problem is inherited from go-live or created by the new change.
Stabilise the agreed operating baseline.
Then improve it deliberately.
Make the vendor show you the implementation plan
Before signing, do not ask only:
“How long will implementation take?”
Ask vendors to show:
Then ask:
What evidence must exist before you recommend that we go live?
A credible implementation conversation should be able to answer that without relying on a standard timeline.
ERP implementation red flags
The project plan contains dates but no acceptance criteria
A milestone should say what must be true, not only when it occurs.
The business has assigned nobody with decision authority
The vendor cannot resolve internal ownership disputes for you.
Data migration is one line near the end of the plan
Migration affects testing, reporting, balances and cutover.
“We will clean the data during migration”
Technical transformation cannot replace business ownership of data quality.
UAT is another vendor demonstration
Acceptance belongs to the business.
UAT uses only clean sample transactions
Real data and real exceptions are where implementation risk appears.
Integration testing proves only successful transactions
Failure handling matters too.
Training happens just before launch with no role-specific practice
Attendance is not readiness.
Nobody can describe what happens if cutover fails
Rollback and continuity should not be invented under pressure.
The support team appears only after go-live
Knowledge transfer has started too late.
Go-live automatically means project closure
The business still has to stabilise.
Phase 2 starts before core issues are under control
New change can hide unresolved implementation defects.
A practical go-live readiness gate
Before approving production cutover, ask whether the evidence exists.
| Readiness area | Evidence to require |
|---|---|
| Scope | Agreed Day-1 scope and accepted deferred items |
| Governance | Named sponsor, champion and functional owners |
| Configuration | In-scope configuration accepted |
| Master data | Business owners have validated critical masters |
| Migration | Dry runs completed and final process understood |
| Balances | Required opening/control totals reconcile |
| UAT | Business users have completed and accepted required scenarios |
| Exceptions | Critical edge cases tested |
| Integrations | End-to-end and failure scenarios tested |
| Security | Production roles/access validated |
| Training | Users required for Day 1 are ready for their roles |
| Cutover | Detailed sequence, owners and verification documented |
| Rollback | Criteria and authority defined |
| Support | Go-live support/escalation is active |
| Communications | Users and affected parties know transition arrangements |
| Go/no-go | Decision authority and acceptance criteria defined |
One unresolved critical dependency can matter more than fifteen completed minor items.
How exactllyERP fits into this implementation
An exactllyERP implementation should be evaluated using the same discipline.
Do not judge it by a generic promise that the software can be installed quickly.
Bring Exactlly:
- the agreed business scope;
- companies and locations;
- current systems;
- master-data condition;
- data that needs to migrate;
- required integrations;
- critical workflows;
- difficult exceptions;
- users and role structure;
- operating calendar;
- cutover constraints.
Then ask us to make explicit:
- what Exactlly will do;
- what your team must do;
- what information or decisions we need from you;
- what will be tested;
- how migrated data will be accepted;
- how cutover will be controlled;
- what support exists around go-live.
exactllyERP can be deployed in cloud or on-premise environments, and implementation details will vary with the agreed scope, deployment, integrations and operating requirements.
There should therefore be no universal implementation-duration claim in this guide.
The correct question is:
What is the implementation plan for this scope, and what evidence will tell both sides that it is ready?
ERP implementation readiness checklist
Governance
Scope
Data
Testing
Users
Cutover
Go-live support
Stabilisation
Go-live becomes a controlled decision rather than an act of optimism.