Bringing an Offshore or Outsourced Dynamics 365 Team Back Under Control

If an outsourced Dynamics 365 team is slow, every change breaks something and only they understand the system, restore leverage before deciding anything about the supplier. First, freeze all non-critical change so production stops moving. Second, require runbooks and a documented environment inventory as dated deliverables that someone outside the team must be able to follow. Third, move source control, pipelines and deployment credentials into your own organization. Fourth, commission an independent review of the code and configuration so you can judge quality yourself. Then choose: re-contract the incumbent on new terms, or transition through a dual-run with a second supplier, a staged handover by area, or a full replacement, each sequenced so production never has two deployment paths.

Why does an outsourced Dynamics 365 team end up holding all the leverage?

Not because it is offshore. Solzet itself delivers remotely, from Yerevan, and distance is not what causes lock-in. Opacity is. Leverage drifts to the supplier when four things happen quietly over a year or two:

• The only copy of the real build lives in the supplier's development environment or repository, so nobody else can reproduce production.
• Deployments are done by hand, by the supplier's people, using accounts and connections that belong to them.
• Knowledge exists in the heads of a few named individuals rather than in documents, and nobody on the client side has checked that the documents that do exist are accurate.
• Nobody independent has ever looked at the code, so every claim about quality, effort and risk comes from the party being paid to do the work.

Once those four hold, slow delivery and fragile releases are not something the client can diagnose, only something they can complain about. The sequence below reverses each one in turn.

What should you do first when every change causes an outage?

Freeze non-critical change. A system that breaks on every release is telling you the release process cannot be trusted, and adding more releases while you work out why makes the investigation harder and the outages more frequent.

• Put the freeze in writing, with a start date and the named person on your side who approves exceptions.
• Define what is still allowed: fixes for incidents that stop the business working, security fixes and changes forced by a Microsoft deadline. Everything else, including small enhancements, waits.
• Require every allowed change to be logged before it is deployed, with what it touches, who approved it and how it will be rolled back.
• Stop direct edits in production. Changes go through a test environment first, even if the path is still manual.
• Tell the business what is frozen and for roughly how long, so the backlog does not turn into side-channel requests to individual developers.

A freeze is also a useful test. A supplier that cooperates with a short, well-defined freeze is one you may be able to keep on new terms. One that resists being slowed down while you understand your own system has told you something about the relationship.

Which runbooks and environment inventory should the incumbent deliver?

Enough that a competent team that has never seen the system could operate it. Ask for them as specific, dated deliverables with acceptance by someone other than the author, not as a general request for "documentation", because general requests produce long documents nobody can use.

• Environment inventory: every environment with its purpose, type, region, administrators and backup position, including developer and sandbox environments nobody mentions in meetings.
• Solution inventory: every solution, managed or unmanaged, its publisher and version, and where the editable source lives.
• Automation and code inventory: plug-in assemblies and their registered steps, cloud flows and classic workflows with owners and the connections they run as, web resources and PCF controls.
• Integration map: every system that connects in or out, the identity it authenticates as, the schedule, and when each secret or certificate expires.
• Deployment runbook: the exact steps to take a change from source to production and roll it back.
• Operational runbooks: for the failures that already happen, the symptom, where to look, what to do and who to tell.

Accept each deliverable by having someone on your side, or an independent party, follow it. A deployment runbook is accepted when someone else has deployed with it. If you want these obligations written into the contract, or need to know what the current contract already requires, take the contract terms to your legal advisers; this post is about the delivery content, not the legal position.

The reverse engineering method for building these inventories from the environment itself, when the supplier cannot or will not, is set out in our guide to taking over an undocumented Dynamics 365 environment.

How do you move source control and deployment credentials to your own organization?

Make your organization the owner of everything a release depends on, while the incumbent keeps working. That means the repository holding the unpacked solutions and code, the pipelines, the service connections those pipelines use, the Entra app registrations and application users behind integrations, and administration of the tenant and each Power Platform environment. The supplier's people then work inside your repository and your pipeline under accounts you can grant and revoke.

The detailed checklist of which roles, identities and repositories to move, and in what order, is on our Dynamics 365 project rescue and takeover page, and the export steps, including why a managed solution in production cannot be turned back into editable source, are in our guide to switching Dynamics 365 partners safely. Two points matter specifically when the incumbent is staying for now:

1. Frame it as ordinary governance, not a prelude to exit. Owning your own repository and pipeline is good practice whoever supports the system, and a reasonable supplier will accept it.
2. Once the move is done, verify it: someone on your side lists the repository, runs the pipeline to a test environment and confirms which identity each integration uses. Ownership that has not been exercised has not been transferred.

Why commission an independent review while the incumbent is still working?

Because until someone independent reads the code and configuration, you cannot tell a supplier who is slow because the system is genuinely difficult from one who is slow because the build is poor, and you cannot tell which outages come from the design and which from careless releases. That distinction decides everything that follows.

The review should be run by a party with no stake in the outcome, chosen by you rather than recommended by the incumbent, and working from read access to the environments and your repository. It should report on the build, not on the people: technical health, customization quality, data integrity, security and fit with the business process, with the evidence behind each finding. That is what our Dynamics 365 health check and technical audit delivers as a fixed-scope, independent assessment, so the method is not repeated here.

Share the findings with the incumbent and ask for a written response. How a supplier responds to evidence about its own work is itself evidence.

Should you re-contract with the incumbent or transition to another supplier?

Decide from the review and the last few weeks of behaviour, not from frustration built up over the last year. The questions below usually settle it.

• Did the review find a build that is broadly sound and a release process that is the main problem? Then re-contracting on new terms, with your repository, your pipeline, a freeze discipline and runbooks as standing deliverables, may be the cheapest way to a stable system.
• Did the supplier cooperate with the freeze, deliver usable runbooks and move credentials without friction? Cooperation under scrutiny is the best predictor that new terms will hold.
• Did the review find poor-quality code, unmanaged changes throughout production or a data model that fights the business? Then the build needs rework whoever does it, and the question is whether the team that produced it is the right team to fix it.
• Are the people who understand the system still on the account? If the knowledge left with individuals the supplier has since moved, much of the lock-in has already gone and a transition costs less than it seems.

Whether to change suppliers at all, and how to choose the next one after a bad experience, is covered in our guide to choosing a Dynamics 365 partner after a failure.

What are the transition options, and how do you sequence each without an outage?

There are three, and all of them share one rule: at any moment there is exactly one controlled deployment path into production, and everyone knows who owns it.

Dual-run with a second supplier. A second team joins alongside the incumbent, in your repository and pipeline, first reviewing the incumbent's changes and deploying to test, then taking changes itself. It suits business-critical systems where knowledge is concentrated in a few incumbent people. Sequence it so the incumbent keeps production releases until the second team has shipped several changes cleanly through test, then move production ownership in one planned step.

Staged handover by area. Ownership moves one module, integration or process at a time, for example service first, then sales, then integrations. It suits systems whose areas are reasonably separate, with an incumbent willing to cooperate for a defined period. Draw the boundaries around solutions and integrations rather than around teams, hand over the lowest-risk area first, and move each area only after the new owner has used its runbooks successfully.

Full replacement. The incumbent exits on a date and the new supplier takes everything. It suits a relationship that has broken down, or a review that found little worth keeping in the incumbent's way of working. It is only safe if the credentials, repository and inventory are already yours. Freeze change for the handover window, have the new supplier deploy a trivial change end to end before the exit date, and rotate every secret the incumbent has seen on the day it leaves.

For dual-run, the second team does not need to be a full delivery team from day one. Senior people working inside your existing process, reviewing the incumbent's changes and learning the system, are enough to break the single-supplier dependency. That is the shape described on our Dynamics 365 staff augmentation and subcontracting page, which also covers how knowledge is kept when an engagement ends.

How do you keep production stable during the transition itself?

By treating the handover as a series of controlled changes, not an event.

1. Keep the freeze in place across each ownership change, and lift it only once the new owner has deployed and rolled back successfully in test.
2. Never let two teams deploy to production in the same window. Write down who owns production releases this week.
3. Before an area or the whole system changes hands, the incoming team deploys one small, real change end to end with the outgoing team watching.
4. Keep the outgoing team reachable for a defined period after each step, for questions only, with answers written into the runbooks.
5. Rotate secrets and remove access for departing individuals as each step completes, after checking nothing still runs under their accounts.
6. Review incidents weekly during the transition, and pause the next step if the last one caused one.

Does regaining control mean staying on Dynamics 365?

Usually, yes. Lock-in to a supplier is a governance problem, and it is fixed by owning your own source, credentials and documentation rather than by changing platform. Occasionally the review shows that the system has been customized so heavily, for a process so specific, that the platform licensing adds little. Solzet recommends whichever fits, Dynamics 365, Power Platform or a custom-built CRM, and in those cases a custom CRM on React, Node.js, PostgreSQL or .NET that you own outright is worth pricing. Decide that after control is restored, not during the crisis.

How does Solzet help bring an outsourced Dynamics 365 team back under control?

We work as the independent reviewer, as the second supplier in a dual-run, or as the incoming team in a staged or full handover. The review is fixed scope and written so you can act on it with any supplier, including the incumbent. As a second supplier, our senior consultants and full-stack developers work inside your repository and pipeline, deliver remotely from Yerevan, Armenia, and bring 8+ years of Dynamics 365 Customer Engagement and Power Platform work across Sales, Customer Service, Field Service and Customer Insights. Where the system is already failing rather than just slow, the project rescue and takeover service starts with stabilization first. We do not take over Dynamics 365 Finance, Business Central, NAV, Finance and Operations or other ERP work.