Managing Finance Systems & ERP Implementation Projects

Accountants get pulled into ERP and finance-systems implementation projects more often than almost any other type of project work, and usually without much formal preparation for it. The technical accounting knowledge translates well; the project itself — data migration, parallel running, vendor management, change management — has its own risks that a general project management foundation doesn't fully cover.

Scoping before selecting

The most common source of ERP project failure isn't the software — it's a scope that was never properly defined before vendor selection began. A finance team that hasn't mapped its current-state processes, identified which are genuinely required versus historical habit, and agreed what "done" looks like is choosing a system against a moving target. Time spent on scoping before a vendor is even shortlisted is rarely wasted, however much pressure there is to move straight to demos.

Data migration: where the real risk lives

Migrating financial data from a legacy system is one of the highest-risk phases of any implementation, because errors here don't just cause inconvenience — they can corrupt the integrity of the new system's opening balances and comparative reporting. A disciplined migration approach treats data cleansing as its own workstream, well before go-live: reconciling legacy balances, resolving duplicate or orphaned records, and agreeing a clear cut-off point rather than trying to migrate a moving general ledger.

Parallel running and cutover

Running the old and new systems in parallel for at least one full reporting cycle — reconciling outputs between them before fully decommissioning the legacy system — remains one of the most effective risk controls available, even though the pressure to cut costs by skipping it is often significant. Cutover, the point of switching over fully, should be planned around a natural point in the reporting calendar (typically a period-end) rather than an arbitrary go-live date chosen purely for vendor convenience.

Change management is not optional

The finance team using the new system daily needs to understand not just how to use it, but why the process has changed and what problem it's solving for them specifically — training on button-clicks without that context produces resentment and workarounds, not adoption. See our guide on making change management a positive experience for your team for the people side of this, which is frequently under-resourced relative to the technical build.

Vendor and stakeholder management

An ERP implementation typically involves the vendor, an implementation partner, internal IT, and the finance team itself, each with different incentives — the vendor and implementation partner are often incentivised to declare success and move to the next phase, while the finance team is the one who has to live with the result. A finance lead who understands this dynamic pushes back on optimistic timelines and insists on genuine user acceptance testing rather than a scripted demo passing for it.

Post-go-live stabilisation

The weeks immediately after go-live are rarely smooth, and budgeting for a stabilisation period — with the implementation partner still engaged and the finance team not yet expected to be fully self-sufficient — prevents the common failure mode of declaring the project "done" the moment the system goes live, only to discover the team can't actually run month-end in it unassisted.

FAQ

How long should an ERP implementation take? This varies hugely by scale, but mid-market finance-system implementations commonly run six to eighteen months from scoping to stabilisation.

Should finance lead the project, or IT? Finance should own the business requirements and sign-off; IT typically leads the technical build, with joint governance throughout.

What's the single biggest predictor of a smooth go-live? Disciplined data migration and cleansing well ahead of cutover, more than any other single factor.

Managing systems implementation well is an increasingly valuable skill as finance functions modernise their tooling. Explore Learnsignal's Project Management CPD courses, and for the agile alternative to a traditional implementation plan see applying agile in finance transformation projects.

Choosing an implementation partner

The implementation partner matters as much as the software itself, and finance teams often underweight this decision relative to the vendor selection. Asking for references from businesses of a similar size and complexity, and specifically asking those references how the partner handled a problem that came up mid-project — not just whether the project succeeded overall — tends to surface far more useful signal than a polished pitch does.

Budgeting realistically for the unexpected

Even well-scoped ERP projects routinely uncover data quality issues, undocumented legacy processes, or integration complexities that weren't visible during scoping. Building a genuine contingency into both budget and timeline — rather than treating the initial plan as fixed and absorbing every surprise as a crisis — is one of the more reliable predictors of a project that finishes close to its revised plan, as opposed to one that finishes badly over its original one.

Treat that contingency as a genuine planning assumption from day one, not an emergency fund to be requested only once trouble has already surfaced.