An ERP implementation timeline sets out the work needed to configure a new system, move the agreed data, test the processes and bring the business onto it. The useful date is the one backed by a scoped plan and named people.
A proposal that says “twelve weeks” leaves several questions unanswered. Which entities move? How much history follows them? Who tests the integrations while the finance team continues closing the existing books?
What should the timeline include?
Ask the implementation team to plan around clear outputs:
| Phase | Output needed before moving on |
|---|---|
| Scope and design | Agreed entities, processes, accounting structure and responsibilities |
| Configuration | Working roles, approval rules, dimensions and required integrations |
| Data migration | Mapped data with documented reconciliation results |
| Process testing | Evidence that ordinary and exception cases work |
| Cutover | Approved balances, ownership and a go-live decision |
| First close and support | A completed reporting cycle and resolution of remaining issues |
These phases can overlap, but their acceptance criteria should stay explicit. Importing data before the chart of accounts is settled can create rework; testing only clean transactions can leave serious gaps for go-live.
What usually changes the amount of work?
History matters. Opening balances, current-year transactions and full transaction history require different extraction and reconciliation work. Agree what the business needs to preserve in the new system and what it can retain in an accessible archive.
Integrations matter too. Each connection needs an owner, test data and a failure process. A working invoice sync is only part of the job if nobody has tested credit notes, retries or rejected records.
Local requirements and the availability of the people making decisions also shape the plan. A controller who can spend one day a week on implementation cannot carry the same workload as a dedicated project lead.
Can you use another customer's timeline as a benchmark?
Use it as a question, rather than a promise. Ask what the customer migrated, which integrations they built and how much work their own team contributed.
Light's All Gravy story describes a migration that included historical transactions and a rebuilt accounting structure. That scope is more informative than a headline go-live date. The ERP migration guide explains how to make those choices for your own project.
How should a vendor support the proposed date?
Request a plan with assumptions, dependencies and customer effort by role. It should identify the decisions that can delay the critical path and when each decision is due.
Ask what happens when testing finds a material problem. A useful plan has room to resolve issues and a named person who can change the cutover decision. It should also describe support during the first close, when the team encounters the complete reporting cycle.
When is the system ready to go live?
Finance should be able to reconcile the agreed opening position, carry out the critical processes and explain the control setup. Users need access and training, while unresolved issues need explicit treatment and owners.
Choose the cutover boundary around the business calendar, including reporting deadlines and peak activity. Record the conditions for delaying or reversing the move before that decision becomes urgent.
Use the ERP selection criteria to compare delivery proposals. If you are considering Light, read how migration to Light works, then bring your entity, history and integration requirements to a Light demonstration. That is enough detail for a meaningful implementation discussion.
