How do we know if we are actually ready to go live on D365 F&O?
Readiness is not a feeling — it is a checklist with owners and evidence. At minimum you need: UAT signed off by business process owners (not the project team), data migration dress rehearsal completed and reconciled, all P1 and P2 defects resolved, cutover plan rehearsed and timed, hypercare team confirmed and rostered, and a documented go/no-go decision with named decision authority. If any of those are missing, you are not ready. The pressure to go live is always intense; the job of the programme manager is to make the risk visible, not to absorb it.
What should a D365 F&O cutover plan include?
A task-level plan with owners, start times, durations and dependencies — not a slide deck. It should cover: legacy system freeze, final data extracts, DMF load sequence with validation checkpoints, integration switchover, user access activation, smoke test scripts and sign-off gates, and rollback trigger criteria. Each task should have a named owner and a fallback owner. Run the full plan as a timed rehearsal before the real weekend — surprises during rehearsal are recoverable; surprises at 2am on go-live Sunday are not.
What does good hypercare look like after a D365 go-live?
A dedicated support team available during business hours (and on call for critical processes like period close) for at least four weeks post go-live. Hypercare needs a triage process: a single channel for users to report issues, a defined P1/P2/P3 classification, and response SLAs. The most common hypercare failures are under-resourcing it — pulling the implementation team back to other projects too quickly — and not distinguishing between bugs, training gaps and change requests. All three look the same to an end user.
What is a realistic rollback plan for a D365 go-live?
Rollback is almost never a realistic option once live transactions have been processed, so the real answer is prevention: thorough testing, a rehearsed cutover, and a clear no-go criteria that everyone has agreed to before the weekend. If rollback is theoretically possible in your scenario (clean environment, no external transactions yet), it requires a defined trigger — who makes the call, by what time, based on what criteria — and a tested process to reactivate the legacy system. Most programmes that claim to have a rollback plan have never tested it.