Quick Summary
A Dynamics 365 implementation succeeds when the work is planned, owned and checked at every phase. This checklist is grouped by phase so enterprise teams can tick items off, assign owners, collect evidence and spot gaps early. Use it as a working tool, not a one-time read.
How to Use This Checklist
A checklist only helps if each line has an owner and proof. For every item, track four things:
| Item | Owner | Status | Evidence |
|---|---|---|---|
| The task to complete | One named person | Not started, in progress, done | A document, a sign-off or a test result |
Tips for using it well:
- Give each item one owner, not a team.
- Define what “done” means before you start.
- Review the list in every steering committee meeting.
- Treat items that stay “in progress” for weeks as risks.
- Adapt it. Remove what does not apply and add what is specific to your business.
What Counts as Evidence
“Done” should be provable. These examples show the kind of evidence to record:
| Item type | Example evidence |
|---|---|
| Decision | Minutes or a signed decision log |
| Design | A reviewed and signed design document |
| Configuration | A configuration record and a passed test |
| Data | A reconciliation report signed by the data owner |
| Integration | A test log and a monitoring set-up |
| Training | Attendance records and a competence check |
| Go-live | A signed readiness review |
Before the Project
Most projects that struggle were unclear before they started: about goals, scope or who was in charge. Settle these points first.
- ☐ The business case states the goals and how success will be measured.
- ☐ An executive sponsor is named and has time for the project.
- ☐ Scope is written down: apps, processes, entities, countries and integrations.
- ☐ The budget approach is agreed, including internal time and post go-live support.
- ☐ The internal project team is named, with agreed time commitments.
- ☐ Partner selection used the same criteria for every candidate.
- ☐ The statement of work defines deliverables, roles, assumptions and change control.
Governance and Planning
Governance is what keeps decisions moving. Without it, issues wait for the next meeting, and scope grows without anyone approving it.
- ☐ A steering committee meets regularly, with decision rights agreed.
- ☐ A RACI chart shows who is responsible, accountable, consulted and informed.
- ☐ The project plan shows phases, milestones and dependencies.
- ☐ A risk register is kept up to date and reviewed weekly.
- ☐ A change control process says how scope changes are requested, priced and approved.
- ☐ Success measures are defined, with baselines where possible.
- ☐ A communication plan covers sponsors, project team and end users.
Requirements and Design
Design is where most of the cost of customization is decided. Challenge every gap, and ask whether a standard feature or a small process change would work.
- ☐ Current processes are mapped for each area in scope.
- ☐ A fit-gap analysis separates standard fit, configuration, extension and gap.
- ☐ Every proposed customization has a business case and an owner.
- ☐ Security design covers roles, access and segregation of duties.
- ☐ Reporting needs are listed, with owners.
- ☐ The solution design is reviewed and signed off by process owners.
- ☐ The design records decisions and the reasons for them.
Environments and Technical Setup
- ☐ The environment plan covers development, test, user acceptance and production, and says who owns each.
- ☐ Source control and a release process are in place, with approvals.
- ☐ Access to each environment is controlled and logged.
- ☐ Refresh and deployment schedules are agreed.
- ☐ A plan covers how Microsoft updates will be handled during and after the project.
- ☐ Performance and capacity needs are understood.
Check current environment and lifecycle guidance on Microsoft Learn for your Dynamics 365 apps, because names and tools change.
Data and Integrations
Data and integrations cause more late surprises than any other area. Start early and give each item a business owner, not only a technical one.
- ☐ A data inventory lists sources, owners and volumes.
- ☐ Rules for what will be migrated and what will be archived are agreed.
- ☐ Data cleansing has owners and deadlines.
- ☐ Mapping from source to target is documented.
- ☐ An integration list names every connected system, the data exchanged, the direction and the owner.
- ☐ Error handling, monitoring and retry rules are defined for each integration.
- ☐ Authentication and access for integrations follow your security policy.
Enterprise-Specific Items
Large organizations add complexity in entities, countries, regulation and scale. These items are easy to leave until late, when they are costly to change.
- ☐ Legal entities, chart of accounts and intercompany needs are designed and agreed.
- ☐ Currencies, tax rules and local requirements are confirmed for each country.
- ☐ Languages and regional settings are planned for each user group.
- ☐ Compliance, audit and retention requirements are documented and met by design.
- ☐ Single sign-on and identity management are configured and tested.
- ☐ Performance testing covers expected volumes and peak periods.
- ☐ Disaster recovery and business continuity expectations are understood.
- ☐ Reporting and consolidation needs for group finance are confirmed.
Testing and Training
Testing
- ☐ A test strategy defines the layers: configuration, end-to-end, integration, data, security, performance and acceptance.
- ☐ Test cases come from real business scenarios and are reviewed by process owners.
- ☐ Defects are logged, prioritized and tracked to closure.
- ☐ User acceptance testing is owned and signed off by the business, not the partner.
- ☐ Results and sign-offs are recorded as evidence.
Training
- ☐ A training plan covers each role, with materials and schedules.
- ☐ Super users are named, trained early and ready to support colleagues.
- ☐ Training uses realistic data and scenarios.
- ☐ Attendance and competence are checked.
- ☐ A plan covers new joiners after go-live.
Cutover and Go-Live
- ☐ The cutover plan lists tasks, owners, timings and dependencies.
- ☐ The cutover and data load have been rehearsed at least once.
- ☐ Rollback criteria and the rollback steps are agreed.
- ☐ A readiness review confirms that criteria are met, with a go or no-go decision recorded.
- ☐ Users have the right access and know where to get help.
- ☐ A support rota covers the first days and weeks.
- ☐ Communication to staff, customers and suppliers is sent on time.
Even with a structured checklist, implementation risks can arise. Review the common Dynamics 365 implementation mistakes and how to avoid them before go-live.
Hypercare and Handover
- ☐ A hypercare period and exit criteria are agreed.
- ☐ Issues are triaged by impact, with named owners.
- ☐ Stabilization tasks and a backlog of improvements are tracked.
- ☐ Support ownership moves from the project team to the operations team with documentation.
- ☐ A post-go-live review records lessons learned and next steps.
- ☐ A plan covers regular Microsoft updates and release management.
Items That Often Get Forgotten
Teams ask for real checklists because the same items are missed again and again:
- Security roles and segregation of duties. Designed late, they delay testing and go-live.
- Performance testing. A system that works with test data may slow down with real volumes.
- Cutover rehearsal. Teams plan the cutover but never practice it.
- Mock data loads and reconciliation. One load is rarely enough.
- Training for new joiners. Training stops at go-live, and new staff are left to learn alone.
- Microsoft updates. Nobody owns testing the regular updates after go-live.
- Access to archived data. Users cannot find old records they need.
Example Go-Live Readiness Criteria
Agree the criteria before the readiness review, not during it. Examples include:
- all critical defects are closed, and remaining defects have an agreed plan
- user acceptance testing is signed off by the business
- the final data load has been rehearsed and reconciled
- every integration has passed testing
- users are trained and have the right access
- the rollback plan has been reviewed
- support is staffed for the first weeks
If a criterion is not met, record the risk and the decision, and do not quietly relax the criterion.
A One-Page View for Your Sponsor
Executives rarely need the full list. Give them eight questions each month:
- Are we on track for the next milestone?
- Which risks need a decision from us?
- Is the scope still the agreed scope, and what has changed?
- How clean is the data, and who owns the gaps?
- Are integrations on plan?
- Is the business engaged in testing and training?
- Are the go-live criteria clear?
- What is the plan if we need to delay?
If answers are vague, treat that as a finding.
Adapting the Checklist for Phased or Multi-Country Rollouts
Many enterprises go live in phases: by business unit, by country or by module. Run the testing, training, cutover and hypercare sections once for each wave, and keep one shared list for design, governance and data standards. Lessons from the first wave should update the checklist for the next, so mistakes are not repeated. Where countries have different tax, language or compliance needs, add a local sub-list owned by a local lead.
Who Should Own the Checklist?
Give the checklist to the project manager, but make each item the responsibility of the person closest to the work. Process owners own design and acceptance, data owners own data, and the technical lead owns environments and integrations. The sponsor reviews the summary, not the detail. If one person tries to own everything, the list will go stale.
Download the Checklist
Get this checklist as an editable spreadsheet with owner, status and evidence columns, so your team can use it in your own project plan.
Next Step
Planning a Dynamics 365 project and want a second pair of eyes on your plan? Talk to our team about Dynamics 365 implementation services.
Conclusion
A checklist does not replace good people or a good partner, but it makes gaps visible early, when they are cheapest to fix. Use it to assign owners, record evidence and keep the sponsor informed.
Review it often, adapt it to your business and treat every unticked item as a question to answer, not a box to hide.
S
FAQs
A good checklist covers the business case and sponsor, governance, requirements and design, environments, data and integrations, enterprise items such as legal entities and security, testing, training, cutover and go-live, and hyper care. Each item should have an owner, a status and evidence that it is done.
Most projects move through initiation and planning, design, build and configuration, data migration and integration, testing, training, cutover and go-live, and support after go-live. Microsoft describes its own phases in its Success by Design guidance, which is worth reading alongside your plan.
Run a readiness review against agreed criteria, rehearse the cutover and the data load, confirm that users are trained and have the right access, agree rollback criteria, and set up a support Rota for the first weeks.
It is a structured review that checks whether the business, the system and the team are ready for the next step, such as design sign-off, testing or go-live. It uses a checklist with agreed criteria and evidence, and it ends with a clear go or no-go recommendation.
Typically, an executive sponsor, a project manager, process owners from each business area, functional and technical consultants, data owners, integration owners, a test lead, a training lead and super users. The exact mix depends on the scope.
Plan several layers: unit and configuration checks, end-to-end process tests, integration tests, data validation, performance tests where volumes are high, security tests and user acceptance testing owned by the business. Record results and sign-off for each.



