Stabilize or Replace a Failing Microsoft Implementation Team

Quick answer When a Microsoft implementation is going wrong, the decision in front of you is not who to hire next. It is whether the team delivering it can be stabilized or has to be replaced, and those are different problems with different costs. Stabilize when the delivery problem is a structure problem: the scope was never bounded, the acceptance criteria were never written down, the environments were never separated, or nobody owns the decisions. A capable team inside a broken structure produces exactly what you are seeing, and changing the team changes nothing. Replace when the delivery problem is a capability problem: the work that exists cannot be made to meet the standard the environment requires, or the people who understood the design are no longer on the engagement. Structure repairs do not create competence that was never there. Four tests separate the two, and they are run against artifacts and not against opinions: the decision record, the environment separation, the build reproducibility, and the acceptance definition. Where two tests disagree, the estate is telling you the problem is mixed, and a mixed answer means stabilize the structure first and re-run the capability tests against the repaired structure before deciding anything about the team. Whichever way the decision goes, the sequence that follows is the same: capture what only the current team knows before it leaves, take custody of the environments and the code, and re-baseline against what is actually built and not against the plan.

The decision here is about your program, not about anyone’s reputation. This page works from criteria and from situations, and it names no firms.

The decision you are actually making

The question arrives as “should we fire them.” It is almost never the useful version of the question.

Two situations produce identical symptoms from where you sit. A schedule that keeps moving, demos that show the same thing twice, defects that reappear after they were closed, and a team that cannot answer what was decided or when. Those symptoms are consistent with a team that cannot do the work, and they are equally consistent with a competent team operating inside a program that never gave them a bounded scope, a decision owner, or a definition of done.

Replacing a team fixes the first situation. It makes the second situation worse, because the replacement inherits the same unbounded scope with less context than the people who just left. That is the failure mode worth naming plainly: a change of team is a reset of context, and context is the thing a struggling program has least of.

So the sequence is: test the structure, test the capability, then decide about the team. In that order, because the structure tests are cheap and they are run against artifacts your own tenant already produces.

The four tests, and what produces the evidence

Each test names the surface that produces its evidence. If the surface is empty, that is itself the finding, and an empty surface is a structure finding and not a capability finding.

Test What you are asking Where the evidence comes from
The decision record Can anyone reconstruct what was decided, by whom, and on what date? The work-tracking system’s own history: the work item revision history and comment trail in Azure DevOps Boards, or the issue history in whatever tracker holds the backlog. Export the history for the ten oldest open items.
The environment separation Are development, test and production genuinely separate, with a promotion path between them? The Power Platform admin center environment list for Power Platform work; the Azure portal resource group and subscription layout, or an Azure Resource Graph query, for Azure work; the site collection and tenant layout in the SharePoint admin center for SharePoint work.
The build reproducibility Can the current state be rebuilt from source, without a person? The repository and pipeline definitions in Azure DevOps Repos and Pipelines, or the equivalent in whatever source control holds the solution. For Power Platform work, the managed solution export from the Power Platform admin center and whether it imports into a clean environment.
The acceptance definition Is there a written statement of what “done” means that predates the work? The signed scope document or statement of work, and the acceptance criteria fields on the work items themselves. A criterion written after the demo is not an acceptance criterion.

How to read the four together. Two or more tests failing on the STRUCTURE side, meaning no decision record and no acceptance definition, is a program that has not been set up to succeed, and the delivery team is not the variable to change first. Two or more failing on the CAPABILITY side, meaning environments that were never separated and a build nobody can reproduce, is work product that will not meet a regulated standard regardless of who continues it.

When two tests disagree, the answer is not to average them. A program with a clean decision record and an unreproducible build has a competent process and an under-skilled implementation, and that is a replace-the-implementation situation, not a replace-the-team situation: the same structure will support new hands. A program with separated environments and no acceptance definition has capable engineers and an absent owner, and that is yours to fix, not theirs.

Stabilize: what it means in practice

Stabilizing is not patience. It is a set of specific changes to how the program is run, made in a fixed order because each one depends on the one before it.

Bound the scope to what is already built. Not to the original plan. Take the inventory of what exists in the environments listed above, and declare that the current release contains those things and nothing else. Everything else moves to a named later release. A program that cannot draw this line has not stabilized; it has paused.

Name one decision owner with the authority to say no. Steering committees do not make delivery decisions at the pace delivery needs them. One person, named, whose decisions the delivery team can act on without a further meeting.

Write the acceptance criteria before the next unit of work starts. In the tracker, on the work item, dated. This is the artifact that ends the loop where a demo is followed by a new requirement.

Separate the environments if they are not separated. This is usually the largest single piece of work in a stabilization, and it is the one most often deferred because it produces nothing a stakeholder can see. It is also the change that makes every subsequent change safe.

Re-baseline the schedule against the bounded scope, and let the new date be whatever the inventory says it is. A stabilization that keeps the original date has changed nothing that matters.

If those five changes are made and delivery does not respond, the structure hypothesis has been tested and failed, and the decision moves to replacement with evidence behind it instead of frustration.

The point at which stabilization has failed

Stabilization is a hypothesis, and a hypothesis nobody can disprove is not being tested. The conditions that close it are written down before the five changes start, not discovered afterwards, because a program that has never agreed what failure looks like finds out by attrition instead.

Four conditions close the stabilize option. Each is stated against an artifact rather than against an impression, so that someone who was not in the room can check it.

The scope line will not hold. The release was bounded to what exists in the environments, and items outside that line keep arriving back inside the current release. Evidence: the work item history in the tracker, queried for items added to the current iteration after the date the scope was declared, with the account that moved each one. Read the account column before drawing any conclusion from the count. Where your own stakeholders are the ones adding the items, stabilization has still failed, and replacing the delivery team will not hold the line either, because the line was never theirs to hold.

Acceptance criteria now exist, and work still comes back. Criteria are written on the work item and dated before the work started, and items are still reopened after they were accepted. Evidence: the state-change history on those items, exported from the tracker, showing the accepted-then-reopened transitions. This is the least ambiguous capability signal on the page, because the structural defence has been removed: the team was told in writing what done meant, before starting, and returned something else.

The environments were separated and the build still cannot be reproduced. A promotion path exists between development, test and production, and a managed solution exported from the Power Platform admin center still fails to import into an empty environment, or a fresh clone still fails to build from the pipeline definition in Azure DevOps Pipelines. Evidence: the solution import log and the pipeline run history, both of which persist and both of which export. Structure was the stated blocker, structure was removed, and the artifact still does not reproduce.

A decision owner is deciding and nothing downstream moves. One person holds the authority to say no, decisions are being issued and dated, and the delivery position does not change against them. Evidence: the decision record created during stabilization, read next to the work item state changes over the same span. Decisions that produce no state change downstream mean the constraint was never the absence of decisions.

When two of these conditions disagree, the artifact outranks the account of it, and the environment outranks both. A tracker showing a held scope line while the environments contain work nobody scoped is not a disagreement to be averaged. It means the tracker has stopped describing the system, which is a finding about the structure and not about the team, and it is repaired before anything is concluded about anyone.

None of these conditions is a deadline and none is a count of weeks. They are states, and a program arrives at them when it arrives. What they buy is the difference between replacing a team because the evidence closed the alternative, and replacing it because everyone is tired.

Replace: how a mid-program transition is done without losing the program

A transition is a custody problem before it is a staffing problem. The order below is set by dependency: each step needs the one before it, and the calendar it runs on is set by the condition of the estate and not by any schedule an incoming team would offer you.

Take custody first, then announce. Custody means the things that stop being available the moment a relationship ends: administrative access, source control, the pipeline definitions, the environment ownership, the deployment credentials, and the documentation wherever it actually lives and not wherever it was supposed to live. Confirm each one by using it, not by being told it has been handed over. An administrator account you have not signed into is not custody.

Verify the inventory against the environments, not against the report. Every solution, site, app, flow, pipeline, integration and scheduled job that exists in the tenant. The Power Platform admin center lists environments and their solutions; the Azure portal lists resources by resource group; the Microsoft 365 admin center and the SharePoint admin center list the collaboration surfaces. What is running is the truth. The status report is a claim about the truth.

Capture what only people know before those people leave. This is the step that is skipped, and it is the one that cannot be recovered afterward. It is treated separately below because it deserves its own answer.

Freeze changes across the boundary. No new functional work while custody is transferring. Defect repairs and security work continue; anything that changes behaviour waits until one team is accountable for the result.

Re-baseline against what is built. The incoming team’s first commitment is made against the verified inventory, never against the outgoing plan. A team that commits to the old date before it has seen the environments is telling you something about how it will handle the rest of the engagement.

Two things this page will not tell you, because the honest answer is that they depend on your contract and your estate: how long the transition takes, and what it costs. Both are set by the size of the inventory and the terms already signed, and any number offered before the inventory exists is a guess wearing a number’s clothes.

What the exiting team has to leave behind

Custody, above, is about taking control of the systems. This is the narrower question of what has to physically exist before the work can change hands at all, and every item is settled by inspection rather than by assurance. Each one is either present or it is not, and the surface that answers the question is named beside it.

Ask for all of it while the relationship still holds goodwill. Every item here is cheaper to obtain before an exit is announced than after.

The environment and tenant map, as an export and not as a description. Every environment, what it is for, who owns it, and what connects to it. Produced from the Power Platform admin center environment list, the Azure portal resource group and subscription layout, and the site inventory in the SharePoint admin center. A diagram drawn in a slide is not this artifact. An export from the admin surface is.

Pipeline and release definitions that live in the repository and not only in a portal. A build configured through a user interface and never committed leaves with the person who configured it. Check the repository for the pipeline definition files themselves, then check Azure DevOps Pipelines for definitions that have no file behind them, and treat the difference as the list of things about to disappear.

The service connection and credential inventory, with expiry dates on it. Which app registrations and service principals exist, what each authenticates to, and when its secret or certificate expires. The Microsoft Entra admin center enumerates the app registrations and their credential expiry; the Power Platform admin center lists connection references and the accounts behind them. This is the item whose absence produces an outage long after everyone involved has moved on.

Anything running under a named individual’s account rather than a service identity. Flows, scheduled jobs, scripts and connections owned by a person stop when that person’s account is disabled, and the account is usually disabled on the exit date. Enumerate them from the flow and connection ownership views in the Power Platform admin center and from the job definitions in whatever scheduler holds them, and reassign each one before the account closes. This is the most common way a transferred program breaks, and it breaks quietly.

Work that exists and has not been merged. Unmerged branches, work in progress, and code that was only ever run from a workstation. Compare the repository’s branch list against the default branch, and ask directly whether anything is run by hand from a local machine. A repository whose default branch does not build what is running in production has not been handed over, whatever the paperwork says.

The open position, stated rather than summarized. Open defects, items closed with a workaround still in force, and behaviour that is known to be broken and was accepted rather than fixed. Evidence: an exported work item query, and a direct question about workarounds, because a workaround in force is rarely written on the item it belongs to.

The decision record with the reasons still attached to it. This one has its own section below, because the reasons are the part no system can reproduce once the people are gone.

When the handover pack and the environments disagree, the environments are right. The pack is a claim about the estate. Reconcile every item on it against the admin surface that produces that item, and carry each difference as an open item with a name against it rather than as a discrepancy to be settled later.

Choosing what shape of team replaces the one that is leaving, and whether that is a dedicated team or a set of contracted individuals, is a separate decision with its own risk profile, and it is handed off below rather than answered here.

Capturing knowledge before an incumbent exits

Knowledge transfer during a live delivery, where an incoming team is being taught while the work continues, is a different engagement shape and it is covered on its own page: knowledge transfer during delivery. This section is about the narrower and more urgent case, which is capture at an exit, when the window is closing.

What is worth capturing is what is not written anywhere and cannot be recovered from the system. Three categories:

Decisions and their reasons. Not the decision, which the tracker may hold, but why the alternative was rejected. This is what stops a new team from re-litigating a settled question or, worse, undoing a deliberate constraint because it looked like an oversight.

Operational knowledge that lives in habit. The order things have to be deployed in. The integration that fails silently if a job runs before another finishes. The configuration that is set by hand after every environment refresh because it was never automated. None of this appears in a repository, and all of it appears in an outage.

Environment and credential reality. Which service accounts do what, which permissions were granted as exceptions and why, and which external systems hold a connection to yours. The Entra admin center enumerates the identities and their assignments; what it cannot tell you is which of them matters and which is a leftover.

Capture these as written artifacts in your own systems, in working sessions recorded and transcribed, and by having the incoming team perform each operational task once with the outgoing team present instead of being described to. A demonstration that has been watched is not knowledge transfer. A task that has been performed is.

Do this before notice is given where the contract allows it. The quality of what you capture is a function of the goodwill in the room, and goodwill is a depleting resource after an exit is announced.

Where this decision hands off

This page owns the decision about a team already engaged. Once the decision is made, the recovery work itself is specific to the platform, and each of those has its own page:

And if you are earlier than this page assumes, and the question is how to choose a partner instead of what to do about the one you have, that decision lives on the Microsoft consulting services pillar.

When changing the delivery party is the wrong call

A change of delivery party is an intervention with a cost of its own, and there are three situations in which making one makes the program worse instead of better. All three are settled by inspection before the decision is announced, and all three are cheap to check now and expensive to discover afterwards.

The program is salvageable with the incumbent. The test is whether the five stabilization changes above were actually made, and what happened after they were. Evidence: the declared scope line with the date it was declared, the acceptance criteria written on the work items and dated before the work started, and the decisions the named owner has issued since. Those are read from the tracker’s work item history and from the decision record. Where the changes were never made, the structure hypothesis has not been tested yet, and there is nothing to conclude about the team from a test that was not run. Where they were made and delivery moved against them, meaning items closing against criteria that predate the work and fewer items reopened after acceptance in the state-change history, the constraint was structural and it has already been removed. Read the incumbent’s own written record beside that. A team that has been asking in writing for a bounded scope or a named decision owner was operating inside the constraint you have just repaired, and the requests and their dates sit in the status reports and the escalation trail. Changing the party at that point discards the context the repair had just made useful.

The failure is scope or sponsorship, not delivery. Evidence: the work item history for the current iteration, read with the account column, which shows the accounts that added items after the scope line was declared. The change log read against the signed scope document, which shows changes accepted with no corresponding change to date or budget. And the decision record read for decisions that were requested and never issued, carrying the requested date and the issued date on each. Where the accounts adding scope are your own, and the unissued decisions are yours to issue, a change of delivery party changes the name on the invoice and leaves the cause in place. The incoming party inherits the same unbounded scope, with less context than the people who left. The single check that settles this one: name the person who can say no, then find a decision they issued that held against pressure. Where no such decision exists in the record, the constraint is sponsorship, and sponsorship does not transfer to anyone you hire.

The timeline cannot absorb a handover. Write down each date that cannot move and, beside it, the artifact that fixes it: a contract clause, a regulator’s notice, a vendor’s end-of-support notice, the retirement date of a system yours depends on. A date with no artifact beside it is a preference and it will move under pressure; a date with one will not. Then size the transition against that date from your own verified inventory rather than from anyone’s estimate. The inventory step above produced it: the environments and solutions, the integrations and scheduled jobs, the credentials and their expiry dates, and the branches that have not been merged. Add the change freeze to that size, because custody cannot transfer while functional work continues across the boundary. Where the fixed date depends on functional change continuing through the window the freeze would occupy, a handover begun before that date causes the miss it was meant to prevent.

When two of these three disagree, neither overrides the other, and what changes is the sequence. Take the case where the diagnosis says replace and the calendar says a handover does not fit. Bound the current release to what the fixed date actually requires, deliver that bounded scope with the incumbent under the five changes above, and run the transition on the far side of the date. A handover begun inside a window it cannot finish in produces both failures at once, a missed date and an incomplete transfer, and the incomplete transfer is the half that persists.

None of this settles whether the incumbent is capable. It settles whether changing the party is the lever that moves this program, and in these three situations it is not.

Choosing what shape of team replaces the one that is leaving, and whether that is a dedicated team or a set of contracted individuals, is a separate decision with its own risk profile, and it is answered on dedicated Microsoft teams versus traditional IT staffing.

Talk to a senior architect

If the four tests point one way and the calendar points the other, that is the conversation to have: Talk to a senior architect.

Frequently Asked Questions

How do we decide whether to stabilize or replace a failing implementation partner?

Run four tests against artifacts and not against opinions: the decision record, the environment separation, the build reproducibility, and the acceptance definition. Two or more failing on the structure side, meaning no decision record and no written acceptance definition, points to stabilizing, because a capable team inside a broken structure produces the symptoms you are seeing and changing the team changes nothing. Two or more failing on the capability side, meaning environments that were never separated and a build nobody can reproduce, points to replacing, because structure repairs do not create competence that was never there. Where the tests disagree, the problem is mixed: repair the structure first and re-run the capability tests against the repaired structure before deciding anything about the team.

How do we switch Microsoft partners mid-project safely?

Treat it as a custody problem before a staffing problem, in dependency order. Take custody first and confirm it by use and not by assurance: administrative access signed into, repositories cloned, pipelines run, environment ownership transferred. Verify the inventory against the environments themselves through the Power Platform admin center, the Azure portal, and the SharePoint and Microsoft 365 admin centers, rather than against the status report. Capture what only people know before those people leave. Freeze functional change across the boundary while defect and security work continues. Then re-baseline the incoming team’s first commitment against the verified inventory and not against the outgoing plan.

What must an exiting implementation partner hand over before the work can be transferred?

Seven things, each settled by inspection against a named admin surface rather than by assurance. An environment and tenant map exported from the Power Platform admin center, the Azure portal and the SharePoint admin center, not drawn in a slide. Pipeline and release definitions committed to the repository rather than configured only in a portal, since a build that exists only in a user interface leaves with the person who configured it. A service connection and credential inventory carrying expiry dates, from the app registrations and their credential expiry in the Microsoft Entra admin center and the connection references in the Power Platform admin center. An enumeration of everything running under a named individual’s account rather than a service identity, reassigned before that account is disabled, because those stop quietly on the exit date. Any work that exists and has not been merged, found by comparing the branch list against the default branch. The open position, meaning open defects and the workarounds still in force, from an exported work item query plus a direct question, because a workaround is rarely written on the item it belongs to. And the decision record with the reasons still attached. Where the handover pack and the environments disagree, the environments are right.

How do we capture knowledge before a partner exits?

Capture the three things that are not recoverable from the system: the decisions together with why the alternatives were rejected, the operational knowledge that lives in habit rather than in documentation, and the environment and credential reality behind the identity assignments. Capture them as written artifacts in your own systems, in recorded and transcribed working sessions, and by having the incoming team perform each operational task once with the outgoing team present rather than watching it described. Do this before notice is given where the contract allows it, because the quality of what you capture depends on goodwill in the room and goodwill depletes once an exit is announced.

FAQPage schema

The four schema entries below are identical in number and in wording to the four visible questions above. Verified by comparison and not by intention. No claim of probe registration is made for any of them, and the v2 claim that three matched registered probes is STRUCK (ruling 01M1AKEMC545JEW43MDC5D0B90 item 3): U61 has no probe registration, and these four are candidate probe subjects owed to the pending-probe register for registration at release.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How do we decide whether to stabilize or replace a failing implementation partner?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Run four tests against artifacts and not against opinions: the decision record, the environment separation, the build reproducibility, and the acceptance definition. Two or more failing on the structure side, meaning no decision record and no written acceptance definition, points to stabilizing, because a capable team inside a broken structure produces the symptoms you are seeing and changing the team changes nothing. Two or more failing on the capability side, meaning environments that were never separated and a build nobody can reproduce, points to replacing, because structure repairs do not create competence that was never there. Where the tests disagree, the problem is mixed: repair the structure first and re-run the capability tests against the repaired structure before deciding anything about the team."
      }
    },
    {
      "@type": "Question",
      "name": "How do we switch Microsoft partners mid-project safely?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Treat it as a custody problem before a staffing problem, in dependency order. Take custody first and confirm it by use and not by assurance: administrative access signed into, repositories cloned, pipelines run, environment ownership transferred. Verify the inventory against the environments themselves through the Power Platform admin center, the Azure portal, and the SharePoint and Microsoft 365 admin centers, rather than against the status report. Capture what only people know before those people leave. Freeze functional change across the boundary while defect and security work continues. Then re-baseline the incoming team's first commitment against the verified inventory and not against the outgoing plan."
      }
    },
    {
      "@type": "Question",
      "name": "What must an exiting implementation partner hand over before the work can be transferred?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Seven things, each settled by inspection against a named admin surface rather than by assurance. An environment and tenant map exported from the Power Platform admin center, the Azure portal and the SharePoint admin center, not drawn in a slide. Pipeline and release definitions committed to the repository rather than configured only in a portal, since a build that exists only in a user interface leaves with the person who configured it. A service connection and credential inventory carrying expiry dates, from the app registrations and their credential expiry in the Microsoft Entra admin center and the connection references in the Power Platform admin center. An enumeration of everything running under a named individual account rather than a service identity, reassigned before that account is disabled, because those stop quietly on the exit date. Any work that exists and has not been merged, found by comparing the branch list against the default branch. The open position, meaning open defects and the workarounds still in force, from an exported work item query plus a direct question, because a workaround is rarely written on the item it belongs to. And the decision record with the reasons still attached. Where the handover pack and the environments disagree, the environments are right."
      }
    },
    {
      "@type": "Question",
      "name": "How do we capture knowledge before a partner exits?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Capture the three things that are not recoverable from the system: the decisions together with why the alternatives were rejected, the operational knowledge that lives in habit rather than in documentation, and the environment and credential reality behind the identity assignments. Capture them as written artifacts in your own systems, in recorded and transcribed working sessions, and by having the incoming team perform each operational task once with the outgoing team present rather than watching it described. Do this before notice is given where the contract allows it, because the quality of what you capture depends on goodwill in the room and goodwill depletes once an exit is announced."
      }
    }
  ]
}