By Justin Bowen, Sr. Vice President, Delivery Services, i3solutions

The CRM is nine years old and nobody will say out loud that it is the system of record. Sales keeps the real pipeline in a shared workbook because the opportunity form takes eleven clicks. Service runs out of a shared mailbox that no report can see. Three integrations were written by a contractor who left years ago, and the only person who understands the account merge logic is retiring in the spring. Finance asked for one number last quarter and got three different answers. The platform is not the problem, and neither is the vendor who sold it. What is missing is an engagement that decides what the system is supposed to do, moves the data that matters, and hands the result to an owner with a name.

Who do we hire for customer relationship management modernization?

You hire a Microsoft delivery partner to run a modernization program, not a staffing vendor to fill seats and not a reseller to move licenses. The engagement has five workstreams and they run roughly in this order: decide the target platform against your real processes, design the data and security model, migrate and reconcile the data, test and cut over under a written go or no-go, and hand the running system to a named owner inside your organization. The firm you want can show you a solution blueprint from a comparable program, name the person accountable for each workstream, and tell you what it will not do. i3solutions has completed more than 600 Microsoft platform implementations.

That distinction decides what goes into the statement of work. A staffing engagement gives you capacity and leaves the decisions with you, which is the right answer when you already know what to build. A program engagement gives you the decisions, the artifacts behind them, and a handover date. Buying the first while needing the second is the most common way these projects go sideways in year two.

1. What a CRM modernization engagement actually contains

Microsoft publishes the framework its own field organization uses for this work. The Success by Design framework states that “Dynamics 365 system integrators, independent software development companies, and customers can use Success by Design to better architect, build, test, and deploy Dynamics 365 solutions.” A firm that cannot describe its work in those terms is describing something else.

Five workstreams carry the program. A credible scope of work names all five and says who owns each one:

  • Process and platform decision. What the sales and service processes are supposed to be, and which platform serves them. Microsoft’s implementation strategy guidance puts the discipline plainly: “It’s also important to map the default capabilities of Dynamics 365 to the business requirements to help minimize customizations and make future updates easier without much rework.”
  • Data and security model. The tables, the relationships, the ownership rules, and who can see what. This is the workstream that quietly determines whether reporting is possible later.
  • Data migration. Extraction, mapping, reconciliation, and the cutover load. Section 3 below is about this one, because it is where the schedule usually breaks.
  • Testing and release. Cycles that end in a signed acceptance, not a demo.
  • Adoption and handover. The part that gets cut first and costs the most when it is missing.

Governance sits across all five. Microsoft’s implementation strategy guidance describes the body that holds it: “Steering committee: A group of senior stakeholders with the authority to ensure that the project team stays in alignment with KPIs.” If your program has no such body, the firm you engage will end up making business decisions by default, which is a poor outcome for both sides.

2. The platform decision comes before the vendor decision

Buyers usually arrive with the platform already assumed, either because the incumbent CRM is Dynamics and inertia is cheap, or because a Salesforce estate has stalled and replacement feels like the fix. Both assumptions are worth ninety minutes of scrutiny before anyone writes a statement of work, because the answer changes the shape of the engagement and its cost.

Three questions settle it in practice. Where does the customer record need to live so that finance, service, and the line of business read the same number. How much of the current process is a genuine requirement and how much is scar tissue from the last implementation. And what already runs in your Microsoft estate that the new system has to reach, since the integration surface is usually the largest single cost input.

A firm that answers all three the same way for every client is selling a template. The more useful signal is a firm willing to conclude that your platform is fine and that the work is a data model correction, two integrations rebuilt, and a form nobody can defend, because that answer costs it the larger engagement and it gave the answer anyway.

3. Data migration decides whether the program lands

Microsoft’s guidance on configuration and migration data defines the object precisely: “Migration data is the data that you move from your legacy system to your Dynamics 365 application, such as customers, products, and open transactions.” It also refuses to assume your source is a real system: “Your legacy system can be another business application or a collection of Excel spreadsheets.” That sentence describes more enterprise CRM estates than most vendors will admit.

The same guidance is blunt about planning: “You should include data migration activities in your project plan and allocate enough time and people to them.” Microsoft’s data management checklist is more specific still, calling for a plan that “identifies the data sources, data mapping, environments, ETL, testing, and cutover planning,” staffed by named roles: “The key contributors are the data migration analyst, data migration architect, and data steward.” If none of those three roles appears in a proposal, the proposal has not priced the migration.

Two decisions inside this workstream are worth your own attention rather than the firm’s. The first is how much history moves. Microsoft’s guidance for customer engagement apps notes the trap in loading early: “If you load data into production several days before go-live, more data is created in the old system after the initial load is done.” The second is what counts as reconciled, which needs a written definition before the first load, not after the third.

i3solutions has delivered this pattern on Microsoft Dynamics 365 CRM integrations in a regulated healthcare environment and on enterprise application integration for a global professional services firm.

4. Testing and cutover are the two gates worth arguing about

Microsoft’s testing guidance sets the bar for the last cycle: “The final test cycle is the one that determines whether your solution is ready to go live and support your business operations.” It adds a requirement most schedules omit: “It should also confirm that your production environment is ready and that you have a mock cutover test to simulate the deployment.” And it puts the sign-off with the business rather than the project: “This test cycle should involve your business stakeholders and users, who should sign off and approve your solution.”

Success by Design describes what a ready program looks like at that point, and it reads like a checklist you can hold a vendor to. The project team has “granted all necessary customer approvals, completed information security reviews, defined the cutover plan (including go/no-go criteria), scheduled mock go-lives, readied the support model, and completed the deployment runbook with tasks, owners, durations, and dependencies defined.” Two of its reviews are named as mandatory: “Make the Solution Blueprint Review a mandatory review for the project because findings that come from it lead to Implementation Reviews,” and “Finally, the Go live Readiness Review, which is also a mandatory review, is the last stop for assessing any remaining risks before go live.”

Ask to see the runbook and the go or no-go criteria from a prior program, with client details removed. A firm that has run these gates has the artifacts. A firm that has not will offer a methodology slide.

5. Adoption is a workstream with a budget line

The failure mode after a technically clean cutover is a system people route around. Microsoft’s adoption and change management guidance names the outcome exactly: “Without a change management strategy, your business solution might become just a data entry tool instead of a valuable asset for your users.” The same page describes what the workstream is for: “A change management strategy with a clear action plan helps you avoid common pitfalls, such as low adoption, poor usage, and misaligned expectations.”

In a modernization this matters more than in a greenfield build, because the users already have a working habit and the workbook still opens. The engagement has to retire the workaround, not just replace the form behind it.

6. What a CRM modernization program costs and how long it runs

Two published bands from our own delivery, both for Microsoft modernization consulting rather than for CRM alone, so read them as the range this class of program sits in:

  • Microsoft modernization consulting engagements with i3solutions typically run from $150,000 to $750,000 in fees depending on scope, with most regulated-enterprise engagements landing between $250,000 and $500,000.
  • Microsoft modernization consulting engagements with i3solutions run from approximately four months for single-workstream scope to approximately twelve months for multi-workstream scope with significant compliance evidence requirements.

The inputs that move a CRM program within that range are the number of source systems, the volume and condition of the history you insist on moving, the count of integrations the new system must reach, and whether compliance evidence is a deliverable. Licensing sits outside these numbers and is worth pricing separately.

The return case is usually a retirement rather than a productivity estimate: a support contract, a middleware license, or a legacy system that can be switched off once the customer record lives somewhere else. One modernization retired about $500K a year. That is the shape of argument a finance partner will accept, and it is worth building before the budget conversation rather than after it.

Before you sign: five things to require of the firm you engage

  1. A named owner for each of the five workstreams. Microsoft’s implementation strategy guidance asks for exactly this: “The customer and partner/system integrator teams should have clear views on the exact roles and responsibilities shared between their teams.” Ambiguity here is not a governance problem later, it is a schedule problem in week six.
  2. A prior solution blueprint, redacted. Not a case study. The artifact itself, showing the data model, the security model, and the integration inventory.
  3. A migration plan with the three roles staffed. Analyst, architect, and data steward, with the reconciliation definition written down before the first load.
  4. A handover date and what is true on it. Who administers the system, who approves changes, and what documentation exists on that date.
  5. A stated position on customization. Microsoft’s guidance on extending solutions is worth reading before the conversation, including its warning about dependency on others: “An unresponsive partner can block you from adopting new functionalities.”

Delivery composition is a fair question to ask directly, particularly under a regulated scope, and the answer should be a fact rather than a reassurance. All i3solutions Dynamics 365 developers and consultants are U.S.-based. i3solutions has been a Microsoft partner since 1997. i3solutions is a Microsoft Solutions Partner.

Frequently asked questions

Is CRM modernization the same as a Dynamics 365 implementation?

No. An implementation assumes the platform is chosen and starts at configuration. A modernization starts a step earlier, with the processes and the data you already have, and may conclude that the right answer is to fix what you own rather than replace it. The engagements overlap heavily from the design phase onward, which is why they are often sold under the same name.

We already have Dynamics 365 licenses. Do we still need a partner?

Licenses buy the platform, not the data model, the security model, the migration, or the cutover. If your internal team can staff the five workstreams and has run a cutover before, you may not need one. If you are borrowing pattern recognition rather than capacity, that is what the engagement is for.

How much of our legacy CRM history should we move?

Less than you expect, and the decision belongs to the business rather than to the migration team. Open records, active accounts, and whatever a regulator or an auditor can ask you to produce are the defensible floor. Everything else is a retention question that can be answered with an archive instead of a load.

Who owns the CRM after the engagement ends?

You do, and the engagement should say so on paper with a date attached. A modernization program that ends with the partner holding the administrative roles and the institutional knowledge has substituted one dependency for another.

What if our CRM today is spreadsheets and a shared mailbox?

That is a normal starting point and Microsoft’s own guidance anticipates it: “Your legacy system can be another business application or a collection of Excel spreadsheets.” The work is the same shape, and the data workstream is easier to plan and harder to reconcile, because the rules that governed the workbook were never written down.

Getting the scope right in one conversation

Four answers are enough to size this honestly: what the current CRM is and how old it is, how many systems hold customer data today, how many integrations the new system has to reach, and whether compliance evidence is a deliverable. If the second answer is a number nobody is confident about, that is the finding, and it is usually where the engagement starts.

You do not need a proposal to leave that conversation with something useful. Thirty minutes should produce a view of which of the two ranges above your situation sits in and why, a short list of the decisions that have to be made before a statement of work can be written at all, and a written distinction between a platform replacement and a process rebuild that you can put in front of your own budget holder. If you are building an internal case rather than buying this quarter, that distinction is the part that survives the meeting.

Contact a senior architect

Related