Implementation speed is a named decision criterion in a large share of finance system evaluations, and it is the number vendors are least specific about, because the honest answer depends on things the vendor does not control.
So here are 2 real ones, with the constraints that shaped them.
Dreamdata went live on all 3 entities on 1 April 2026, with a controller who had joined the company in February. He walked into a migration already in motion and was 6 weeks from cutover. All Gravy had a Head of Finance and Ops who joined in February to decide whether to go ahead at all, and a finance analyst who joined mid-April and inherited the migration. Neither company had a project team. Both had 3 people in finance and a business that did not pause.
between Dreamdata's controller joining and go-live on 1 April, across 3 entities
transactions in All Gravy's Danish entity alone, all migrated and reconciled
people in finance at each company, with no dedicated implementation team
What actually drives the number
How much history moves. The single biggest lever, and the one most timelines quietly avoid. Taking an opening balance is fast. Moving every transaction is not. All Gravy moved its full history back to January 2020, reconciled against trial balances year by year before import. Dreamdata migrated opening balances at 31 December 2025 plus every 2026 transaction line by line, because it was audited and mid-raise and refused to let January look different from July.
Both chose the slower option deliberately. A clean start leaves a permanent seam in the record, and every year-on-year comparison afterwards crosses a system boundary.
Whether the chart of accounts gets rebuilt. All Gravy's predated the company becoming a SaaS business, with department reporting running on dedicated GL accounts rather than dimensions. Carrying that forward would have been faster and would have moved the problem rather than solving it. Rebuilding it, with custom dimensions for department and country from day 1, added time and is the reason reporting works now.
How many systems are being replaced. All Gravy replaced 7: 4 ledgers, a card provider and 2 payment platforms. Each one has its own data, its own cutover and its own set of people who need to stop using it. Oper Credits went from 8 systems to 3. That count predicts elapsed time better than company size does.
Entity count and local requirements. 4 markets means 4 sets of local compliance to satisfy, and the slowest one gates the group cutover.
What does not drive it
Company headcount, mostly. All Gravy has 65 people and Dreamdata around 50, and neither number tells you much. The finance function's complexity is what matters, and a 40 person company with 4 entities and bespoke contract terms is a longer project than a 300 person company with 1 entity and standard billing.
Vendor methodology, mostly. Every serious vendor has phases in a deck. What predicts the actual date is who answers when something breaks in week 6.
"ERP migrations are painful as a general rule. You can have a less painful experience or a very painful one. The Light team answered us at very late hours of the night, which matters when you are three people running a project this size."
Sebastian Sandorff Jacobsen, Head of Finance and Ops, All Gravy
Adds weeks
Full history, reconciled
Every year checked against its trial balance before import. Slower once, and it removes a seam the company would otherwise carry permanently.
Adds weeks
Rebuilding the structure
A chart of accounts fit for what the company is now, with real dimensions. The only cheap moment to do it is during a migration.
Saves weeks
Replacing fewer systems
Each system retired is its own cutover. The count of systems predicts elapsed time better than headcount does.
Sequencing that works
The pattern in both projects is the same and it is worth copying.
Decide the structure before moving anything. Chart of accounts, dimensions, entity model. These are the decisions a company lives with for a decade and the only inexpensive time to make them is before the data lands.
Reconcile before importing, not after. Year by year, against the trial balance the old system produced. A migration that lands unreconciled data is a data transfer with a reconciliation project bolted to the far end, and that project is where timelines actually die.
Cut over at a boundary the business understands. Both companies went live at a point where the year could be presented as one continuous record.
Expect the tail. Go-live is not the end. Dreamdata invoices from Light while its contracts module is still being built out with the product team, because its terms need 13 and 14 month recurrences and it has no list prices anywhere in the business. Treating that as work in flight rather than a failed implementation is the correct framing, and any vendor claiming there is no tail is describing a simpler company than yours.
The number to plan against
For a company at this size with a handful of entities, plan for a few months rather than a few weeks, and expect the variance to come from how much history moves and how much structure gets rebuilt rather than from anything the vendor does.
The thing worth optimising is not the date. It is what the finance function looks like 6 months after it. All Gravy closes 4 countries in 5 days with 3 people while the company doubled, and its bookkeeping partner spends 30 to 40% less time on the books than before. That is the return the timeline is buying, and shaving 3 weeks off the project by skipping the history or keeping the old chart of accounts is how companies end up paying for the migration twice.
Read how All Gravy moved 6 years of history, see the selection criteria that matter, or book a demo.