The First 90 Days in Production: What Nobody Tells the Finance Team

Alex at FitGap

17 Apr 2026 — 7 min read

The first 90 days in production — where systems are tested in reality, not in design.

The system went live. The project team is celebrating. The implementation partner is wrapping up. The steering committee is disbanding.

And the finance team is about to discover that none of what they prepared them for was the right preparation.

Go-live readiness is almost universally defined as a technical question. Is the system configured? Is the data loaded? Did UAT pass? These are legitimate checkpoints. But they measure whether the system is ready — not whether the finance team is ready to operate it. Those are two completely different things, and the gap between them is where the first 90 days falls apart.

This article names the four failure modes that show up in the first 90 days of production — not the ones in the project risk register, but the ones nobody warned the finance team about.

1. The Readiness Criteria Gap

Every implementation has a go-live checklist. It covers system configuration, data migration validation, integration testing, user access, and cutover completion. What it almost never covers is operational readiness — the finance team's actual ability to run the system under real conditions.

There is a critical difference between these two things.

System readiness asks: is the system ready to go live? Operational readiness asks: is the team ready to operate the system when something goes wrong?

These questions require completely different answers. A system can be fully configured, fully tested, and fully loaded — and the finance team can still be completely unprepared for production. Because the conditions of production are nothing like the conditions of UAT.

In UAT, scenarios are controlled. Happy-path transactions are tested repeatedly. Testers know which process they're validating. The implementation partner is in the room. Errors get logged and resolved without urgency.

In production, the bank file needs to go out at 3pm. The payroll integration runs tonight. The period closes in four days. Nobody knows which transaction triggered the posting error, the implementation partner's hypercare contract ends next week, and the key user who knows the configuration is on vacation.

Operational readiness requires a different kind of validation — one that asks not "did this work in testing?" but "does the team know what to do when this fails in production?" Most go-live checklists don't ask that question at all.

2. The Multi-Participant Process Breakdown

The second failure mode appears within the first weeks of production, and it follows the same pattern every time.

A cross-system process fails. Not because the integration was built incorrectly — it was tested, it passed UAT. It fails because the conditions in production are different from the conditions in testing, or because a scenario outside the happy path surfaces for the first time, or because one participant in the process didn't follow the agreed procedure.

Payroll integrations and bank payment files are the most common examples. The payroll file comes in from HR, gets processed through D365, and needs to post to the General Ledger before payments go out. The bank payment file gets generated in D365 and transmitted to the bank. Both processes involve multiple teams — Finance, IT, HR, the bank, sometimes a third-party payroll provider — operating on tight deadlines with no margin for coordination failures.

What breaks is almost never the technology. What breaks is the coordination.

Someone didn't send the file at the agreed time. The format changed slightly. A new pay element appeared that wasn't in the original mapping. The person who usually handles the exception was in a meeting. The escalation path wasn't clear so nobody escalated until it was too late.

These failures are predictable. The procedure exists on paper. But the procedure was designed, approved, and signed off during implementation — by people who had never actually run it under production conditions. The difference between knowing a procedure and having internalized it through repetition is enormous, and that gap is widest in the first 90 days.

The practical fix is simple and almost never done: before go-live, organize standing coordination meetings for every cross-system process that involves multiple participants. Weekly for the first month, biweekly after that. Put them in the calendar before go-live. Include Finance, IT, the relevant business unit owners, and the integration counterparts. Use them to review what ran, what didn't, and what edge cases surfaced. Don't wait for something to break before getting everyone in the same room.

💡 FitGap Toolkit: If you need a clear structure for who owns what in each cross-system process — with explicit escalation paths — the ERP RACI Matrix + Role Descriptions covers this directly → https://fitgapfinance.gumroad.com/l/erp_raci_roles_responsabilities

3. The Configuration Knowledge Gap

This is the failure mode nobody names explicitly, but every finance team that has been through a go-live recognizes it immediately.

During implementation, key users validate outcomes. They attend workshops, review functional design documents, test scenarios, and sign off on UAT. Their job is to confirm that the system produces the right results. If the trial balance reconciles, if the vendor payment posts correctly, if the purchase order workflow triggers as expected — they approve.

What they are almost never required to understand is why.

Key users validated that the system works. They were not required to understand how it is configured to work that way.

This distinction does not matter during implementation. It matters enormously in production.

In production, a posting error appears. The subledger doesn't reconcile to the General Ledger. The bank statement import creates duplicate transactions. A vendor invoice posts to the wrong account. The key user who owns this process is now the first line of support. They are expected to triage the issue, determine whether it's a configuration problem or a process problem, and either resolve it or escalate to the right person.

None of this is possible if they only know what the correct outcome looks like — not how the system produces it.

The configuration knowledge gap shows up for the first time at the worst possible moment: during month-end close, under time pressure, when the implementation partner may no longer be available on short notice. Key users discover that the gap between "I know this works" and "I know why this works and how to fix it when it doesn't" is wider than anyone anticipated.

The fix requires a deliberate investment before go-live that most programs skip. Not more user training — key users have had user training. Configuration knowledge transfer: targeted sessions where the implementation partner walks key users through the specific configuration decisions behind the processes they own. Not "here's how to post a journal." But "here's why the posting profile is set this way, here's what happens if it changes, here's the first place to look when this transaction doesn't post as expected."

This is different from training. It is the difference between knowing how to drive a car and knowing enough about how it works to diagnose why it won't start.

→ See also: Key Users: ERP Project Realities

→ See also: ERP Warning Signs

4. Ownership Collapse at First Reconciliation

The final failure mode is the most predictable and the least addressed.

Key users accepted their post-go-live responsibilities during the project. They were told they would be the internal experts. They agreed. They understood — in the abstract — what that meant.

What they did not understand was what it felt like in practice.

The moment of ownership collapse is not at go-live. It is at first reconciliation, when the first real problem appears and the responsibility becomes concrete.

The payroll accrual doesn't match. The intercompany elimination is off. The fixed asset disposal posted to the wrong account and the period is about to close. The key user who owns this area now has to decide: do I know enough to fix this? Do I know who to call? Do I know how to document this for the auditors?

For most key users, the answer to all three questions is no — and they discover this for the first time under time pressure. The implementation partner may still be reachable but is no longer contracted to hold their hand. Their manager hasn't been briefed on what operational support looks like. The escalation path exists on paper but nobody has actually tested it.

This is not a failure of the key user. It is a failure of the transition design. Key users were prepared for implementation — not for operations. The skills required to validate a configuration in UAT and the skills required to own a financial process in production are not the same skills.

What this requires is a structured transition plan that explicitly maps, before go-live, who owns each process in operations — not just which team, but which named individual — along with a clear escalation path, a documented first-response procedure for the most likely failure scenarios, and a schedule for the first three period-end closes that includes explicit support touchpoints.

The transition plan is not a project deliverable. It is the sponsor's responsibility to mandate it before the project closes.

→ See also: ERP Governance Is Non-Negotiable

Final Thought

The first 90 days in production are harder than the last 90 days of implementation. Not because the technology is harder — it isn't. Because the support structure is thinner, the stakes are higher, and the people responsible for the outcome are operating a system they understand less well than they thought.

None of this is inevitable. Every failure mode described in this article is predictable and preventable. The readiness criteria gap closes when someone asks "is the business ready to operate?" as a distinct question from "is the system ready to go live?" The coordination vacuum closes when standing meetings are scheduled before go-live, not after the first failure. The configuration knowledge gap closes when key users receive targeted configuration knowledge transfer, not just end-user training. The ownership collapse closes when the transition plan names people, not teams, and includes escalation paths that have been tested before they're needed.

These are not complex interventions. They are the things that almost never get done because the project team is focused on delivering the system — not on building the operation.

The question to ask right now: when the implementation partner leaves, who holds the map?