The kickoff meeting runs two hours. The partner shows a twelve-week timeline, an org chart of their team and a slide that says "data migration: week 9". On the client side, nobody knows who will decide how products get coded, or who will clean up the 4,000 duplicate customers in the old system. Week 9 arrives, the question comes up anyway, and the timeline slips a month.
Picking a Dynamics 365 partner in Chile solves part of the problem. You still need to know what happens during a Dynamics 365 implementation, what your own company has to do, and how to tell a Dynamics 365 consultancy that manages risk from one that just configures screens. This guide starts from the framework Microsoft itself recommends and maps it to what you'll see on a real project.
If you're still working out which product you need, Dynamics 365 Business Central: what it is and when it fits covers the SMB ERP, and Enterprise CRM software: how to choose one people use has the criteria for the sales side.
The phases of a Dynamics 365 implementation
Microsoft uses a framework called Success by Design (the page was updated in August 2026). It doesn't replace your partner's methodology. It adds reviews meant to catch risks before they get expensive. The phases work as a map for almost any project:
| Phase | What happens | What should be done by the end |
|---|---|---|
| Discover | Requirements are gathered and validated, and the overall approach is set | High-level scope and a first design review |
| Initiate | Workstreams are defined and the plan is adjusted | Current and future processes, approved scope |
| Implement | Design, configuration, development and testing, process by process | A solution built and tested end to end |
| Prepare | User acceptance testing, training and the go-live plan | Trained users and a rehearsed cutover |
| Operate | Stabilization and the next round of improvements | Working support and a prioritized backlog |
Two reviews are mandatory. The first is the solution blueprint review, which starts during Discover. The second is the go-live readiness review, the last risk check before production. In between, teams can run focused reviews on the data model, security, integrations or test strategy.
Your partner doesn't have to use these names. What you should see is something equivalent: a design that gets reviewed before anyone builds, and a formal checkpoint before go-live.
What your company has to do
A lot of projects fall behind on the client side. An implementation needs people from your company with hours actually blocked in their calendars, because goodwill doesn't survive month-end close. The minimum roles:
- A sponsor: a manager who settles conflicts between departments and approves scope changes. Without one, every decision sits and waits.
- An internal project lead, who coordinates schedules, chases answers and works day to day with the partner's project manager.
- Key users for each process (sales, finance, warehouse, service) who know the operation, validate the design and run acceptance testing.
- Someone who owns the data. Microsoft's implementation guide calls this role the "data steward": they set data rules and quality criteria and coordinate with each area.
- IT, for access, integrations with other systems, security and licensing.
Ask the partner how many hours a week they expect from each role, and in which weeks. If they can't answer, part of the plan is missing.
Data migration: where most projects trip
Migration tends to look like a technical task for the end of the project. It almost never is. Microsoft's implementation guide on data migration recommends defining the strategy before the project starts and updating it as things move. It separates master data (customers, products, vendors) from open transactions (pending sales and purchase orders, stock on hand, open balances). It also says to migrate only what's relevant to the new solution, and to test the migration at least once in the system integration and user acceptance test environments, not for the first time on cutover day.
In practice that means making three decisions early.
- How much history comes over. Five years of invoices, or just opening balances? Bringing everything costs more and takes longer, and many companies keep the old system in read-only mode for history.
- Who cleans the data. The partner can provide tools and templates, but deciding which of three records for the same customer is the right one is your team's job.
- How many rehearsals. A migration that runs for the first time on go-live weekend is a bet. Ask for at least one full rehearsal, with record counts and reconciliations signed off by each department.
Adoption: the system works and nobody uses it
Going live and having people actually use the system are different things. Success by Design places training in the Prepare phase and recommends doing it by process and by role. A salesperson learns how to move an opportunity forward; they don't need a tour of every menu.
What helps most, from what we see on projects:
- Train with your company's own data instead of demo data.
- Have key users who can answer day-to-day questions during the first weeks.
- Agree on a support period with the partner after go-live, with a clear way to report problems.
- Measure real usage: how many people log in, which processes get recorded in the system, and which ones still live in spreadsheets.
Signs of a good Microsoft partner
Microsoft grants the Solutions Partner for Business Applications designation to partners that score at least 70 out of 100 points across performance, team certifications and customer success. You can check a provider's designations in the Microsoft partner finder. It works as a first filter, but you still have to ask the harder questions:
| Question | Answer that builds trust | Red flag |
|---|---|---|
| How do you map processes? | Workshops per process, with written results the client validates | "We'll figure it out during configuration" |
| What if something doesn't fit the standard product? | They first look at adjusting the process; if they build, they explain what it costs to maintain | Custom development for everything |
| How do you handle migration? | Their own plan, rehearsals and named owners on both sides | "Just send us an Excel file" |
| Who will work on the project? | Names, roles and committed time | A team you meet after signing |
| What happens after go-live? | Agreed support, with response times and a defined channel | The project ends on cutover day |
| Do you know the local context? | They handle SII electronic invoicing and Chilean accounting practices | Everything depends on a third party they won't name |
Also ask for references from clients with a scope similar to yours, and talk to them without the partner on the call.
Large projects have one more option. Microsoft offers FastTrack for Dynamics 365, where Microsoft architects support customers above a minimum annual license spend. To use it, the partner needs the Solutions Partner for Business Applications designation, at least two eligible deployments and completed Success by Design training. If your project might qualify, bring it up in the first meeting.
Frequently asked questions
How long does a Dynamics 365 implementation take?
It depends on the product, how many processes are in scope, the integrations and how much history you migrate. Rather than a general number, ask for a phased timeline with verifiable milestones and the time commitment expected from your team.
Can I implement Dynamics 365 in stages?
Yes, and it's usually the sensible choice. Starting with the critical areas, stabilizing them and then adding modules lowers risk and lets you learn from the first stage.
Who owns data quality?
Your company. The partner brings method, tools and validation, but business rules and record cleanup need someone internal with the authority to decide.
How we do it at Disrupsoft
We implement Dynamics 365 in stages, starting with the critical areas. We begin with a review of your sales and finance processes, connect the platform to Microsoft 365, Power Platform and the systems you already run, and after go-live we stay on with training and support. We've worked with Microsoft and systems integration since 2013.
If you're evaluating an implementation, tell us where your project stands.
