Microsoft Dynamics 365 Implementation Checklist

Dynamics 365 projects fail predictably. The failure is almost never the product. It is that the customer starts the implementation before the questions the implementation will ask them are answered. This checklist covers the thirty-two items you should have written down before the vendor arrives, so the discovery phase produces a plan rather than another workshop. It draws on the same discipline we use in every Dynamics 365 engagement and our broader platform implementation service.

TL;DR

• Have licensing decided, and named. The wrong SKU is the most common scoping error.
• Have the entity model on one page. Custom entities that appear in week six cost weeks to unwind.
• Have SSO and provisioning ready. A leaver who keeps access is an audit finding.
• Have data migration scoped as its own phase. Nobody has ever underestimated it enough.
• Have an adoption plan with a named owner. The rollout is not the implementation.

Before the vendor arrives

Licensing (five items)

1. Which apps: Sales, Customer Service, Field Service, Finance, Supply Chain, Project Operations, Marketing. Named, not "we will decide during discovery".
2. Number of licences by type. Full user, activity user, device. Get the count wrong and the SOW is wrong.
3. Included storage and where you will exceed it. Attachments and email tracking are the usual culprits.
4. Environment plan. Development, test, production, and any additional sandboxes. Each has a cost.
5. Whether Power Platform is included in the plan or needs a separate licence. This changes the customisation options materially.

Entities and data model (six items)

1. The out-of-the-box entities you will use unchanged. This is the largest set and often the least discussed.
2. The out-of-the-box entities you will extend. Custom fields, custom views, custom forms.
3. The custom entities you need. This is the list the implementer needs before day one, not week three.
4. The relationships between entities. Many-to-many, cascade behaviour, ownership.
5. The audit scope. Which fields you must track changes on, retained for how long.
6. The reporting requirements. Aggregations, calculated fields, views. Model them before the entities are locked.

Security roles and access (five items)

1. The roles. Named by job function, not by named person. Roles change less than people do.
2. The security model. Business units, teams, ownership rules. Reversible only with pain later.
3. SSO against your identity provider. Microsoft Entra ID is the default; other IdPs are supported but need testing.
4. Automated provisioning through SCIM or Entra ID group membership. Manual provisioning survives about six months before someone forgets.
5. Deprovisioning path. What happens the day someone leaves. This is the audit finding.

Integrations (six items)

1. The systems Dynamics must talk to. CRM, ERP, marketing automation, data warehouse, telephony, custom apps. Named, with owners on each side.
2. The direction of integration. Read, write or both. Bidirectional is not the default answer, it is the expensive answer.
3. The pattern. Real time via API integration, batch via Data Factory or Synapse, event-driven via Power Automate. Choose per integration.
4. The identity of record for each shared field. Which system wins when they disagree. Written down, not agreed verbally.
5. The failure mode. What happens when the other system is down or the payload is malformed. Retry, queue, dead letter, alert.
6. The API integration work is a separate line item, sized against the count above.

Data migration (five items)

1. The source systems. Every one, including the spreadsheets nobody wants to admit exist.
2. The field mapping. Column by column, with a decision for every unmapped field. Discard, transform, store in a custom field.
3. The data quality baseline. Duplicate rate, completeness, validity. Cleaning is a phase, not a task.
4. The migration plan. Full or phased, cutover date, rollback plan, reconciliation approach.
5. The signoff. Who accepts that the migration is complete. Named person, not a committee.

Customisation and code (three items)

1. The customisations you know you need. Plugins, workflows, PowerFx, business rules. Documented before implementation, not invented during.
2. The boundary between platform customisation and external services. What sits inside Dynamics and what sits in your own systems. Reversible only with rework.
3. The developer environment. Solutions, source control, deployment pipeline. Skipped in small projects, missed in every large one.

Adoption (two items)

1. The training plan. Sessions, audience, materials, recording. Adoption is the single largest source of failure and the cheapest to fix.
2. The named owner post-launch. The person who will care about this in six months. Without them, the platform degrades.

What the checklist actually saves you

Two to four weeks of implementation time in most projects. The discovery phase is bounded by the questions that need answering. If the answers exist before discovery starts, discovery becomes verification rather than a fresh conversation. That collapses week one to two into a review, and week three moves from "we still do not know the entity model" to "the entity model is signed."

It also saves the argument about scope in week eight. When the customer says "we need this custom entity that was not in the SOW", the implementer can point to the checklist and ask which item was missed, rather than negotiating a change from a blank page. Our note on fixed scope software delivery covers why that discipline matters even for platform work, and the internal tools development guide covers where Dynamics 365 fits against lighter alternatives.

Where Dynamics implementations still overrun

• Reporting. The out-of-the-box reports do not answer the questions the executive sponsor actually cares about. Model these before entities are locked, not after.
• Integrations. Every one takes longer than estimated. Double the estimate for anything touching a legacy ERP.
• Data quality. Nobody has clean data. The cleaning phase is usually three weeks and always feels wasted at the time.
• Adoption. Sales teams will use whichever tool has fewer clicks per record. If Dynamics has more clicks than the spreadsheet, they will use the spreadsheet.
• Change requests. A change per week is normal. A change per day means the scope was wrong from the start.

When Dynamics is the wrong answer

If your organisation is not on Microsoft 365, Dynamics loses most of its licensing and integration advantages. If your workflow is genuinely simple, HubSpot, Pipedrive or a well-configured Retool app get you there faster. If the sales motion is heavily custom and revenue depends on it, custom software is often the honest recommendation. Our full build vs buy for internal software method covers how to make that call without a vendor in the room.

Frequently Asked Questions

How long does a Dynamics 365 implementation take?

A focused single-module implementation typically ships in 6 to 10 weeks. A multi-module rollout with several integrations and data migration usually runs 12 to 20 weeks. Larger enterprise rollouts across Sales, Service and Field Service can take six months or more, and the length is driven by integration count and data quality rather than user count.

What is the most common cause of Dynamics implementation failure?

Starting before the questions on this checklist are answered. Every item that is undecided at kickoff becomes a change request during the build, and change requests are what turn a ten-week project into a twenty-week one. The vendor is not going to make you answer them. You have to.

Do we need a Dynamics partner, or can Microsoft implement it?

Microsoft FastTrack can help with the enablement phase, but it is not a full implementation service and it does not handle the parts that involve your other systems. For anything beyond a single module on a small team, an independent partner is usually the better fit because they own the whole scope including integrations and migration.

How much does a Dynamics 365 implementation cost?

Licensing is billed per user per month by module, ranging from about $65 to $210 per user per month depending on the module. Implementation cost varies from around $14,000 for a scoped single module to well into six figures for a full enterprise rollout. The build is driven by integration count, customisation depth and data migration scope rather than user count.

Should we use Power Platform for customisations?

Yes for most cases, no for a few. Power Platform is the intended extension surface for Dynamics 365 and covers most of what teams want to customise: forms, workflows, small apps, reporting. Move to code plugins only when the logic exceeds what PowerFx can express or when the performance requirement demands it. The Microsoft Power Platform service covers the boundary.

Can we integrate Dynamics with our existing tools?

Yes, through several patterns depending on the tool. Dataverse has direct connectors to Microsoft 365, Azure and common SaaS. Power Automate handles event-driven integrations. Data Factory or Synapse handle batch. Custom REST integrations are available for anything else. Every integration is its own project, and the timeline is set by the worst one.

How do we migrate data from our old CRM?

As a phase with its own scope. Audit the source, produce a field-by-field mapping document, clean the source data, run a dry migration into a sandbox, reconcile record counts and key fields, then cut over with a rollback plan ready. Common gotcha: activity history, notes and attachments often carry more surprises than the master records.

What about ongoing support after go-live?

Dynamics needs the same maintenance as any other production system. Licence renewals, security updates from Microsoft, changes as your business changes, and someone to answer "why did this record change" when someone asks. Retainer engagements typically start around $1,750 per month for a small implementation and scale with the size of the deployment.

Ready to scope a platform implementation? Book a free 45 minute scoping call. We will map the workflow, name the platform decisions that matter, and give you a written scope before you commit.