We have been in more go-live planning meetings than We can count.
And in almost every one, the conversation follows the same pattern.
Someone asks: when do we go live?
A date is given. Usually one that was decided months ago, before a single test had run.
Then the meeting moves on.
Nobody asks the harder question: how will we know when we are actually ready?
That question — and the absence of a real answer — is responsible for more painful D365 go-lives than any technical problem I have encountered.
This edition of CrestCode is about the difference between having a go-live date and having a release readiness framework. And why only one of those things protects the business.
The problem most teams do not see until it is too late
Every D365 programme has a go-live date. It is in the project plan, in the steering committee slides, and in the email the CIO sent to the board six months ago.
What most programmes do not have is a structured answer to a different question: on what basis will we decide that the system is ready to support live business operations?
UAT passing is not that answer. UAT answers a different question entirely — can users execute today’s business processes in the new system? It does not answer whether those processes will continue to work after the next Wave update, after a new customisation goes in, or after the data migration surfaces an edge case nobody thought to test.
The teams that go live confidently are not the ones with the most test cases. They are the ones who built a release readiness framework before testing started — and ran every release decision against it.
The 5-component release readiness framework
A release readiness framework does not need to be complex. It needs to answer five questions that most programmes leave unanswered until the week before go-live.
Component 01: Release criteria defined before testing starts. What percentage of tests must pass before a release is approved? What constitutes a critical flow? What defect severity classifications exist, and which ones block go-live? These decisions need to be made in writing, agreed between QA and the business, before a single script runs. Not negotiated under pressure the night before deployment.
Component 02: A named release owner with clear authority. Not a committee. Not the project manager by default. One person — named, accountable, and empowered to say no. The release owner’s job is not to make the date work. It is to make the decision correctly. That distinction matters enormously when a critical defect surfaces in the final week.
Component 03: Risk-weighted test coverage mapped. Test coverage prioritised by business risk, not test count. Finance processes, integrations, and approval workflows validated first and in full. Low-risk UI flows validated last or deferred to hypercare. The question is not how many tests ran — it is whether the right ones did.
Component 04: An agreed defect classification framework. A shared definition of P1, P2 and P3 that QA and the business have signed off on before testing begins. What blocks a release. What goes to the backlog with a documented risk decision. What gets fixed in hypercare. When this framework does not exist, every defect becomes a negotiation. And negotiations in the final week are always resolved in favour of the date.
Component 05: A documented sign-off trail for every release. Every go-live decision recorded. Who approved it. Against which criteria. On what date. Reviewable by anyone in the business in five minutes. This is not just governance hygiene — it is your protection when something goes wrong after go-live and the question becomes who signed off and on what basis.
When these decisions happen determines everything
The difference between a confident go-live and a painful one is not usually the quality of the testing. It is when the decisions that govern the testing were made.
Mature teams define their release criteria at programme kick-off. They name the release owner before the first test is written. They agree defect classifications in the planning phase, not the deployment phase.
Most teams do these things reactively — at the point of pressure, when the date is imminent and the stakes are highest. That is the worst possible moment to be making governance decisions for the first time.
Release readiness is not what you check on go-live day. It is what you build into the programme from day one.
What good looks like
When a release readiness framework is working, you stop having the same stressful conversations before every deployment.
The go / no-go decision takes under thirty minutes — because the criteria were agreed upfront and the evidence against them is already documented.
The release owner can say no — and does, when the evidence requires it. The go-live date is a target, not an override mechanism.
Finance and operations have signed off separately from UAT, because their critical flows have been validated independently by people who understand the business risk, not just the test results.
Every open defect carries a documented risk decision — not just a status. A named person has reviewed it and signed off that it is acceptable to carry into production.
Post-release monitoring is planned before go-live. The hypercare plan exists. Escalation paths are named. The team knows exactly what to watch in the first seventy-two hours.
Closing thought
Go-live is a date on the calendar.
Release readiness is a decision you earn — through criteria defined upfront, ownership that is real, coverage that is risk-weighted, and sign-off that is documented.
The date will arrive whether you are ready or not.
The framework is what determines which of those two things is true.
Crestech helps D365 and ERP teams across the US and UK build release readiness frameworks, QA governance models and test automation programmes that hold. Subscribe to CrestCode for a new edition every Tuesday. DM to discuss your release readiness approach.
