Microsoft partner transition
Change partner.
Not your entire platform.
DependencyControl
Sometimes the Microsoft platform is not the problem. The relationship around it is. A controlled transition starts by deciding whether changing is justified at all, establishing which supplier relationship is actually changing, understanding what exists, securing customer control of the estate and identifying what depends on the incumbent, before responsibility moves.
Changing partner should not mean changing everything.
The safest partner transition starts before the old relationship ends.
The objective is not simply to move a support contract. It is to understand what the business depends on, what has been customised, what connects to what, who has access, what is currently failing, what is undocumented, what is already committed, and what needs immediate attention.
In short
Ten things a leadership team should take from this page.
The goal is not to make changing partner sound easy. It is to make it controlled.
- 01Changing partner does not automatically mean changing platform.
- 02First decide whether changing is justified at all.
- 03Identify which supplier relationship is actually changing.
- 04Separate live support transition from active implementation takeover.
- 05Establish what you control and what you depend on.
- 06Assess whether the estate can be supported responsibly.
- 07Transfer knowledge and prepare the future service.
- 08Move responsibility only when readiness evidence supports it.
- 09Stabilise, then operate the contracted scope properly.
- 10Improve only where the evidence justifies it.
Worth saying plainly
Changing partner will not fix every problem.
An evidence-led review may conclude that changing partner is not currently the right intervention. Some difficulties sit with the supplier relationship. Others sit inside the organisation, with another supplier, in the platform history or in the data.
Internal ownership
Nobody inside the business owns the platform decisions.
Another supplier
The constraint may sit with an ISV, an integrator or a data supplier.
Uncontrolled customisation
Change has been added faster than it has been governed.
Weak data
A reporting argument is often a data argument.
Unclear process
The system reflects a process nobody has agreed.
Expectations
What was contracted and what is expected may not match.
Customer resourcing
Support needs people on both sides of the relationship.
Historic decisions
Some constraints were set years before the current partner.
Technical debt
Deferred work compounds regardless of who holds the contract.
Poor adoption
A capable system used badly still fails the business.
Retain the current arrangement
Reasons a review may recommend staying where you are.
Not every enquiry should become a transition. Where the evidence points at something else, that is what we will say.
Evidence does not justify a transition
The reported difficulty is real, but changing supplier would not address it.
The issue is internal ownership
Decisions, priorities or process ownership need resolving first.
The issue sits with another supplier
An ISV, integration or data relationship is the actual constraint.
Expectations need clarifying
The contracted service and the expected service are not the same thing.
Current environment risk
Immediate change would add risk the business cannot currently absorb.
Can we actually move?
The concern is rarely the new agreement.
It is what the existing partner knows that the organisation does not. Each of these concerns is answerable.
- Only our partner understands the customisations.
- We do not have the source code.
- We do not know how the integrations work.
- We are not sure what access they hold.
- Our documentation is incomplete.
- We have development in flight.
- We have outstanding support cases.
- We do not understand our own environments.
- We cannot afford disruption.
- We do not know where to begin.
First establish which relationship is changing.
We record role, capability, contract owner, support responsibility, access, dependency, renewal or notice information supplied by the customer, and the transition decision for each relevant supplier. We do not interpret another supplier's contract.
- Implementation partner
- Support provider
- Microsoft licensing or CSP provider
- ISV provider
- Integration supplier
- Data or BI supplier
- Managed infrastructure provider
- Changing one relationship does not automatically require changing every other relationship
Taking over support for a live platform and taking over responsibility for an active implementation are different risk decisions.
Where active delivery is involved, project health, implementation methodology and recovery should be considered before delivery responsibility is accepted.
- The platform is already operational
- The primary decision is how service responsibility transfers
- Focus on supportability, access, knowledge, active incidents and the future service
- Business continuity governs the timing
Two different stages
Assessment before the decision. Onboarding after it.
A pre-decision review should help you decide. Transition onboarding establishes what is required to accept operational responsibility. They are not the same piece of work, and they should not be presented as one.
- A bounded assessment may establish supportability
- Key risks and transition dependencies
- Likely complexity of a transfer
- Whether switching is justified at all
- This should not commit you to InteliSense
- Whether a formal Partner Transition Assessment is an approved chargeable service is a commercial decision that has not been confirmed, so no commercial model is stated here
How transition works
Decide, understand, secure, transfer, then take responsibility.
Complexity determines transition effort. A well-documented standard environment needs less than a heavily customised estate with multiple integrations and active projects, so we do not publish a universal duration.
Decide
Whether changing is justified, and which relationship changes.
Discover
Understand the business before taking on the technology.
Secure customer control
Administration and approved access held by you.
Inventory
Establish what actually exists across the estate.
Transfer or reconstruct knowledge
Structured sessions, documented outcomes, named gaps.
Assess supportability
Evidence, risk and what needs attention first.
Prepare service
Define the future operating model before the date.
Transfer responsibility
When readiness evidence supports it.
Stabilise
Reduce avoidable operational uncertainty.
Operate
Run the contracted scope properly.
Review
Then optimise, recover, transform or change nothing.
Improvement is an optional branch after review, not the conclusion of every transition.
Discover
Understand the business before taking responsibility for the technology.
Support decisions are business decisions. Discovery starts with what cannot stop working.
- Business-critical processes
- Platform landscape
- User population
- Current support model
- Current pain and known risks
- Projects already underway
- Important business periods
- Key stakeholders
- Current suppliers
The objective is to establish what the customer controls, what contractual rights exist and what dependencies remain.
The customer does not automatically own every artefact. Exact arrangements vary by platform and contract, and where rights are unclear the contractual position should be reviewed independently.
- Tenant administration
- Environment administration
- Repositories and source artefacts
- Deployment pipelines
- Domains
- Application registrations and service identities
- Integration credentials and gateways
- Documentation
- Licensing relationships and supplier portals
- The customer does not automatically own every artefact, and arrangements vary by platform and contract
Source access and source rights
Having a copy of source code and having the right to use it are different questions.
Supportability depends on access. Modification and transfer depend on the contract. We are careful not to conflate the two.
- Repository and access
- Latest source version
- Build artefacts and deployment package
- Dependencies and third-party libraries
- Documentation
- Ownership
- Applicable use and modification rights
Service identities and credentials
Do not remove a supplier identity until the dependency is understood.
Do not leave it indefinitely simply because the dependency is unclear. Non-human identities are where transitions quietly break.
Identify
Every non-human identity the estate actually uses.
Understand dependency
What stops working if it is changed or removed.
Create or transfer
A replacement identity where that is appropriate.
Validate
Confirm the dependent process still operates.
Rotate or revoke
When the replacement is proven, not before.
Record
Owner, purpose and status, kept current.
- Service accounts
- Application registrations and service principals
- Managed identities
- API keys, certificates and secrets
- Power Automate connections
- Gateways
- Integration users
- Scheduled-task identities
- Model or AI service connections where relevant
Missing documentation is a risk to manage, not a reason to remain permanently dependent.
Solution design, architecture, process, configuration, customisation, integration, security, data, support procedures, deployment and known issues all help. None of them should stop the transition from starting.
Where the programme is
Where recovery takes it
We cannot move, the documentation is poor
The gaps become a managed transition risk
Only the partner understands it
Knowledge is transferred, reconstructed or recorded as a gap
We do not have the source code
The exposure is named, owned and planned for
They may not cooperate
The plan does not depend on perfect cooperation
Transfer what matters
Knowledge transfer should be structured, not a sequence of unstructured calls.
Some missing knowledge may be reconstructed from the available estate and operational evidence. Gaps that cannot be resolved remain explicit transition risks.
- Architecture
- Finance
- Supply chain and warehouse
- Manufacturing
- CRM
- Power Platform
- Integration
- Data
- Customisation
- Support and known issues
- Security and deployment
- Recorded where agreed
If cooperation is limited
A transition plan should not depend entirely on perfect cooperation.
Evidence can also come from the platform itself, the customer team and the operational history around it.
- The live platform and its configuration
- The customer team
- Support history
- Repositories
- Microsoft environments
- ISVs
- Logs and monitoring
- Whatever documentation does exist
- Data and testing
Confidence gates
Responsibility should move because the service is ready, not simply because the notice period ended.
Four points where continuing has to be re-earned. Each can legitimately conclude that the transition should be delayed, limited, or not happen at all.
Gate 1
Transition viability
Is changing partner the right intervention at all?
Confirmed before transition work begins, and before anybody assumes the answer is yes.
Confirmed at this gate
- Which relationship is changing, and why
- Customer decision owner and platform or service scope
- Critical business processes and existing suppliers
- Active implementation status
- Contractual or notice constraints known to the customer
- Required access and likely transition dependencies
Decision
Proceed · Assess further · Delay · Retain the current arrangement · Recovery first
Gate 2
Supportability confidence
Can this estate be supported responsibly?
Confirmed on evidence rather than optimism. Unsupportable is a legitimate answer.
Confirmed at this gate
- Critical processes understood and estate sufficiently inventoried
- Access available, and source, build and deployment position understood where relevant
- Integrations and ISVs identified
- Active incidents understood
- Documentation and knowledge-transfer gaps visible
- Security and access risks understood, and service boundaries understood
Decision
Supportable · Supportable with remediation · Further evidence required · Recovery required · Unacceptable risk at present
Gate 3
Responsibility-transfer readiness
Is the new service ready to operate?
Responsibility should move because the service is ready, not simply because the notice period ended.
Confirmed at this gate
- New service scope, ticket route, priority model and escalation
- Customer contacts and customer communications
- Active incidents and open development ownership
- Third-party routes and Microsoft cases
- Monitoring where contracted, deployment and change window
- Service identities, incumbent-access plan and business-calendar risks
Decision
Go · Defer · Limited transition · Remediate first
Gate 4
Operating acceptance
Is the transition actually complete?
Confirmed after transfer. A transition is not complete when the old partner leaves.
Confirmed at this gate
- New access functions and critical processes remain operable
- Ticket route proven and escalations work
- Active items have owners and support tooling functions
- Residual knowledge gaps are recorded and inherited risks have actions
- Former-partner access is removed or controlled according to plan
- The customer accepts the operating transition
Decision
Transition complete · Extended stabilisation · Further remediation · Recovery
Controlled overlap
Instant switchover is not the only model.
Where your contracts and circumstances allow, an overlap can help with active incidents, Microsoft escalations, work in flight, knowledge transfer and service continuity. It is not mandatory, and we cannot promise incumbent cooperation.
Current service
The incumbent arrangement continues as contracted.
Knowledge transfer
Structured, wherever cooperation is available.
Controlled overlap
Where customer contracts and circumstances allow.
Responsibility transfer
On the agreed date, against readiness evidence.
Stabilisation
The new service settles before anything is improved.
A transition is not complete when the old partner leaves. It is complete when the new service model is ready to operate.
Actual coverage, hours, priorities and exclusions depend on the agreed contract. We do not publish service levels on this page.
- Applications, environments, integrations and ISVs covered
- Support route and hours
- Priority principles and escalation
- Customer responsibilities
- Deployment responsibility and change route
- Third-party coordination
- Proactive monitoring where explicitly contracted
- Exclusions
- Actual coverage depends on the agreed contract, and we do not publish service levels here
Service cutover
Every active item needs an owner before the date.
Cutover is a service event rather than a technical one. What matters is that nothing important becomes unowned at the moment responsibility moves.
- Active incident ownership
- Open Microsoft and ISV cases
- Change and deployment activity in flight
- Customer support contact and priority route
- Escalation and supplier routes
- Monitoring where contracted
- Service identities
- Former-partner access plan
- First-day contacts and customer communication
- Business-calendar conflicts
Open items
Do not blindly import an old backlog and call it the new roadmap.
Everything open at the point of transition needs a classification, an owner and a decision.
Incident
Expected capability is not working. It gets a named owner before responsibility moves.
Problem
A recurring pattern understood at root cause, not simply inherited.
Change
Business priority revalidated before it is scheduled.
Obsolete
Confirm whether the item is still required at all.
Discovery required
Not enough is known yet to classify it responsibly.
Transition timing should follow business consequence, not administrative convenience.
Consider whether risky releases should be deferred around the transition. We do not impose a universal change freeze.
- Month end and year end
- Payroll
- Peak trading and seasonal demand
- Production and manufacturing shutdown
- Warehouse stock count
- Major releases and major integration changes
- Regulatory deadlines
- Implementation milestones
- Acquisition or carve-out activity
- Consider deferring risky releases around the transition rather than imposing a universal change freeze
A controlled transition makes supplier boundaries explicit rather than assuming the new partner owns everything connected to Microsoft.
Where obligations are unclear, they should be established from your own agreements and, where required, with independent contractual advice.
- The decision to transition
- Its own contracts
- Business priorities
- Access approval
- Process and data ownership
- Commercial decisions
- Factual validation
The transition should leave the customer with more control of its estate than it had before.
Not every transition requires every artefact. The pack should be proportionate to the size and criticality of the estate.
- Estate inventory: applications, environments, integrations, ISVs and customisation
- Access register: relevant customer, InteliSense and third-party access
- Dependency map: business process, platform, integration, supplier
- Knowledge-transfer register: known, transferred, missing, risk, owner
- Backlog classification: incident, problem, change, obsolete, discovery required
- Supportability view: evidence, impact, risk, owner and action
Security and confidentiality
Partner transition is a natural control point.
It is one of the few moments where every identity, permission and supplier account is examined at once. It also requires privileged access and sensitive information, so the controls should be proportionate.
- Least privilege and named accounts
- Temporary privileged access with an agreed end date
- Audit and approved access
- Data minimisation
- Secure evidence transfer
- Removal of temporary access
- Confidentiality obligations
- Restricted commercial and project material
- We do not make legal or compliance guarantees
Transition control detail
What a takeover examines, area by area.
The depth sits here rather than in the executive layer. The full position for each discipline lives on its specialist page.
After responsibility moves
Take control. Stabilise. Operate. Then review.
A relationship model rather than a delivery guarantee. We do not promise specific outcomes by a particular day.
Take control
Know what we are responsible for.
Stabilise
Reduce avoidable operational uncertainty.
Operate
Run the contracted scope properly.
Review
Then decide, on evidence, whether anything more is justified.
Not every support customer needs an optimisation programme.
If the platform works, meets the business requirement, is supportable and carries controlled risk, the right answer may simply be to support it well. Optimise, Recover, Transform and no change are all legitimate conclusions.
Where transition can lead
Seven honest outcomes, decided by evidence.
Transition may confirm that good support is all that is needed. It may also surface something larger, or confirm that nothing should change yet. Replacement is a recommendation inside Transform or Implement, never a route of its own.
Retain current arrangement
The evidence does not justify a transition.
Transition to Support
The environment is sufficiently supportable as it stands.
Transition with targeted remediation
Specific issues need controlled action alongside the transfer.
Project health or delivery assurance
An active implementation requires deeper assessment first.
Recover
Stability or confidence materially needs restoring.
Optimise
A stable platform has a justified improvement opportunity.
Transform or Implement
Material operating or platform change is justified. Replacement, where evidenced, is a recommendation inside this route.
What good transition looks like
Seven signs the transition has been done properly.
None of them require the previous relationship to be criticised.
Control
The customer understands and administers the estate.
Access
Required access is appropriately governed and recorded.
Knowledge
Critical processes and technology are understood, and gaps are named.
Ownership
Responsibilities are clear across every supplier.
Continuity
Support moves without unnecessary business disruption.
Visibility
Known risks are documented rather than absorbed quietly.
Roadmap
Improvement is separated from the transition itself.
Customer experience of working with InteliSense
What our published evidence does and does not show.
Our customer evidence is published in the customer's own words and reflects delivery and support experience. It is not offered as proof of a partner switch, a support takeover, a transition duration, improved support or long-term retention.
- How InteliSense controls a transition
- The lifecycle, the confidence gates and the control pack
- Available today, and described on this page
Transition router
Where would a transition conversation start for you?
Five questions, kept at organisational level. The result is a likely starting point rather than a recommendation, and one of the possible answers is that the current arrangement is worth retaining.
Indicative signal
Answer the questions and we will show a likely starting point. This is orientation rather than a recommendation, and one of the possible answers is that the current arrangement is worth retaining. Please keep every answer at organisational level.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Common questions
Questions organisations ask before changing Microsoft partner.
Considering a change?
You do not have to decide what happens to the whole platform before discussing a change of partner.
We can start by understanding what you have, what the business depends on, which relationship is actually changing and whether changing partner is the right decision at all.