Planning a Q1 Go-Live? Do the Runway Math

Every October through December, ERP partners get the same call: we want to be live on the new system for the new fiscal year. It's a sensible instinct. A January 1 cutover gives you clean opening balances, a tidy year boundary, and an accountant who isn't reconciling two systems across a fiscal year-end. The date is rarely the problem. The runway is.

The phases you can't skip

A mid-sized implementation has a shape, and the shape doesn't compress well. Discovery, where the partner learns how your jobs actually move from estimate to invoice, takes two to three weeks when it's done honestly. Design and configuration take another month or more. Data migration needs at least one full dry run, usually two, because the first one always surfaces ten years of duplicate vendors and jobs that were never closed. Training has to happen close enough to go-live that people remember it, and then comes the step most owners haven't heard of: the parallel run.

A parallel run means operating both systems through at least one real month-end. It feels like doubled work because it is, briefly. It's also the single best predictor of a calm go-live, because it proves the new system can carry a real close before you depend on it.

Working backwards from January

Put those phases on a calendar, ending at a late-January cutover. The parallel run has to cover the December close, which means training lands in early December, which means migrated data has to be proven by late November, which means design is locked in October, which means discovery started in September.

That's the math. A clean Q1 go-live for a company of any real complexity is a September decision. By mid-November, the honest window for 'live January 1' has mostly closed, and a partner who tells you otherwise is compressing something you'll miss later.

What compression actually cuts

A compressed timeline doesn't shorten the calendar. It shortens the invisible parts: the second migration dry run, the training for the second shift, the parallel month-end. The project still 'goes live' on the date. Then January is dramatic, the team quietly falls back to the old spreadsheets, and the system spends its first year being worked around instead of worked in. Compressing the runway doesn't get you a faster project. It gets you a worse one.

The honest alternatives

• Go live at the start of Q2 instead. A quarter boundary gives you most of the clean-cutover benefits, with a runway that actually fits the work.
• Keep the January date but cut scope, not quality: core financials and job costing first, field tools and integrations as a planned phase two.
• Use the winter properly: start discovery now, build through the slow season, and go live before the busy season starts instead of during it.

Nobody flips a switch at midnight

One more myth worth retiring: even on a January 1 plan, nobody actually cuts over at midnight on New Year's Day. A good go-live is a boring Tuesday at the end of a parallel run, when the team already trusts the system because it has already carried a real close. The cutover itself is paperwork, not an event.

If a new system is on your radar for next year, the most useful thing you can ask any partner, including us, is for the week-by-week plan behind the date. We've been building those plans at Summit since 1991, and we'd rather tell you 'Q2' in November than explain a rough January in February.