Should You Go Live With Your New ERP on January 1?

Somewhere in your steering committee pack there is a slide that says the new ERP goes live on January 1. Nobody remembers deciding it. It appeared in the first plan because January 1 is the obvious date, and it has stayed there because moving it feels like admitting the project is late. It is now the start of Q4, testing has not finished, and the people you need for cutover have already booked their Christmas leave.

An ERP go-live on January 1 is not a bad idea by default. For some companies it is exactly right. But it is a decision with real costs, and the time to make it deliberately is now, while there are still three months to change it. After mid-November the date usually stops being a choice and becomes a hostage situation. Below is how we weigh it with clients, and what to do if the answer is no.

Why January 1 is so tempting

The case for January 1 is almost entirely about finance, and it is a real case. You start the new fiscal year in the new system with no opening balances in the middle of the year, no year-to-date figures to migrate, and no comparison reports that have to stitch two systems together. The old system closes its last full year and is then frozen. Auditors see one system per year. Depreciation, budgets, VAT periods and intercompany agreements all restart on the same day. For a multi-entity group, especially after an acquisition, that simplicity is worth a lot.

There is a second reason that has grown over the last few years: regulation tends to change on January 1 as well. Belgium made structured B2B e-invoicing over Peppol mandatory from January 1, 2026. Germany ends the transition for invoices from larger issuers on January 1, 2027, according to the German Federal Ministry of Finance. If your new ERP is the thing that makes you compliant, the calendar may be choosing the date for you.

What January 1 actually costs you

The problem is that the fiscal calendar and the human calendar collide in the worst possible way. A January 1 go-live means your cutover runs over the Christmas and New Year period. The people who know the data best are the ones most likely to be on leave. Your implementation partner is running on a skeleton crew. The suppliers and customers you need to test integrations with are closed.

Then the first working week arrives, and the same finance team that has to learn a new system is also closing the old year: accruals, stock counts, the VAT return, intercompany reconciliations and the first conversations with the auditor. The new system is at its most fragile precisely when finance has the least attention to give it. ArcherPoint, a Dynamics partner, makes a further point that is easy to miss: training finished in November is half forgotten after two weeks of holiday.

• Cutover weekend lands when key users, IT and the partner are least available.
• Integration partners (banks, logistics providers, EDI customers) cannot test with you.
• Finance is closing the old year and stabilising the new one in the same weeks.
• The first month-end close on the new system falls in a month that already has extra work.
• If go-live slips by a week, you lose the clean fiscal start anyway, and now you have the holiday problem too.

When January 1 is the right call

We say yes to January 1 when most of the following are true. The first is that the date is driven by something outside the project: a legal deadline, the end of a transitional service agreement, a regulatory obligation, or a merger that takes effect on that day. That was the situation at Culligan Belgium, where the merged sales team had to sell from one product range and one price list from January 1, and ERP and CRM had to be aligned before the year-end close. The date was not negotiable, so the whole plan was built backwards from it.

• The date is fixed by something outside the project, not by a slide.
• User acceptance testing finishes by mid-November, with a full dress rehearsal of the cutover before December.
• The key users and the cutover team have agreed, in writing, not to take leave in the last two weeks of December and the first week of January.
• Year-end closing work on the old system is planned and staffed separately from the go-live.
• Opening balances will be loaded after the old year is closed, and everyone accepts that this may take until February.
• There is a hypercare team in place for January that is not the same people who are closing the books.

If you cannot tick most of those boxes by the end of October, January 1 is no longer a clean start. It is a risk you are taking for a reporting convenience.

The alternatives, and what each one costs

Go live at the start of February or March

The most common alternative, and usually the best one. The old system closes the year properly, finance is not fighting two battles at once, and you migrate opening balances plus one or two months of transactions. The cost is a mid-year migration of year-to-date figures and a year in which reporting spans two systems. Modern ERPs handle a mid-year start well; the harder work is agreeing up front how management reports will combine the two periods, and building that report before go-live rather than after.

Go live after the first quarter

Starting on April 1 aligns with a quarterly VAT period and gives finance a quarter-end rather than a year-end to work around. It also gives you the first quarter to finish testing without pressure. The risk is that the extra time is not used: a deadline that moves by three months without a change in scope or staffing tends to produce the same problems three months later.

Go live on January 1 with a reduced scope

If the fiscal start really matters, split the go-live. Finance, purchasing and the general ledger go live on January 1, which gives you the clean year. Warehouse, production planning or the customer portal follow in February, when the people who run them are back and the first close is behind you. This adds a temporary interface between old and new, which has its own cost, but it takes the most operationally sensitive parts out of the holiday window.

A decision checklist for this month

Put these questions to your project team and your implementation partner in the next steering committee. If the answers are vague, that is your answer.

1. What, specifically, requires January 1? A contract, a law, a merger date, or habit?
2. What is the latest date user acceptance testing can finish and still leave time for a full cutover rehearsal?
3. Who is on the cutover team, and what leave have they booked between December 20 and January 8?
4. Who is doing the year-end close on the old system, and are they the same people who need to support the new one?
5. What is the plan if cutover fails on December 31? Is there a rollback, and who decides?
6. If we moved to February 1, what would we lose, in money or compliance, not in reputation?

So, should your ERP go live on January 1?

January 1 is a good date when something outside the project fixes it and the organisation is staffed to meet it. It is a poor date when it is only there because it looks tidy on a plan. The clean fiscal start is real, but it is a reporting benefit, while the risks of a holiday cutover land on operations, customers and the first close. Most of the time, a go-live in February with a properly closed old year is the calmer and cheaper choice.

Whichever date you choose, what happens in the weeks after it matters more than the date itself. We cover that in What Happens After Go-Live, and in our post-go-live support service.

What Happens After Go-Live

How to Run a 12-Week ERP Implementation

Case study: Culligan Belgium, aligned before year-end

Post-go-live support

Sources

ArcherPoint: why you should not plan an ERP go-live in January

German Federal Ministry of Finance: FAQ on the e-invoice (E-Rechnung)