Skip to content
Managed Support

Development Partner Transition

Your development partner is winding down. Your systems still have to run.

When a long-standing supplier exits, the risk is not the code. It is the knowledge walking out with them. We take ownership of established Microsoft estates through a structured transition: knowledge transfer while the outgoing team is still there, shadow support while they still hold the SLA, then full ownership.

Get a free 30-min consultation All managed support
Why organisations move

When a supplier relationship reaches its end

Most partner transitions are planned and amicable. That is exactly why they are worth doing properly.

Your partner is winding down

The firm that has run your systems for years is closing its development arm, has been acquired, or is exiting your sector. Notice is coming and you need a successor before it lands.

The relationship has run its course

Nothing has gone wrong, but the pace of change has stalled. You want a partner who will challenge the assumptions built up over a decade rather than defend them.

The estate has outgrown the supplier

Your systems moved to the cloud, added integrations, and grew a device estate. The incumbent has kept the lights on but cannot cover Azure, security, and data alongside development.

Concentration risk on one supplier

A single firm holds the knowledge, the access, and the deployment keys for a business-critical application. Your board wants that risk reduced before it becomes an incident.
What transfers

Everything your outgoing partner holds

A transition is not a code drop. It is knowledge, access, operational responsibility, and the assurance that the estate is under your control.

Knowledge transfer while it is still available

Structured sessions with the outgoing team while they are still contracted and still cooperative. We capture architecture decisions, deployment quirks, and the workarounds that live in people rather than documents.

Access, licences, and control

Source control, Azure subscriptions, DNS, certificates, secrets, app store accounts, and third-party licences transferred into your ownership. We produce a register of everything and confirm each item is under your control.

Documentation generated from the code

AI-augmented codebase analysis produces architecture maps, data flows, dependency inventories, and API specifications from the system as it actually is, not as someone once intended it to be.

The regression suite you never got

Automated regression testing is the most common gap we inherit. We build coverage around the highest-risk paths first, so the first release under new ownership is safer than the last one under the old.

Operational ownership

Monitoring, alerting, incident and problem management, and an agreed SLA. We take responsibility for the system being available, not just for the tickets raised against it.

A roadmap, not just continuity

Once the estate is stable and understood, we plan what comes next: modernisation, reporting, integration, and the improvements the previous arrangement could not deliver.

An example of a structured 24-week takeover from an outgoing partner, with accounts moving into the client's ownership and risks closing until the first monthly report at full ownership. Illustrative data for a fictional client.
AI-augmented transition

Read the whole estate, not a sample

AI lets our engineers work through every repository, stored procedure, and work item the outgoing partner left behind. A person checks every finding before it reaches you.

Reading the whole estate in a development partner transition: inputs, AI analysis, human review, and outputs you own
A four-tier layered architecture for reading the whole estate during a transition. The Inputs tier, what we inherit, holds walkthroughs recorded with AI notes, source and SQL from every repo and procedure, work-item history covering years of bugs and changes, and live signals from monitoring and tickets. In the highlighted Analyse tier, AI does the legwork: it maps code paths (callers, dependencies, and data), drafts user journeys for each critical function, and clusters known issues from the work-item history. In the Review tier, people decide: an engineer checks every finding, the outgoing team confirms while still in contract, and your service desk checks against real calls. The Outputs tier, which you own, holds a knowledge base, a known-issues register, runbooks, a readiness scorecard, and a technical debt backlog.
Roadmap

How a 24-week transition overlaps

The phases are not sequential. Knowledge transfer, documentation, and shadow support run in parallel while the outgoing partner still holds responsibility.

A 24-week development partner transition: six overlapping workstreams from estate assessment to full ownership
A Gantt roadmap for a 24-week development partner transition, with six workstreams that overlap rather than run in sequence. Estate assessment (code, cloud, and risk) runs in weeks 1-4 and produces an assessment of architecture and security, plus a risk register. Access and control (ownership transfer) runs in weeks 3-8, as repos, Azure, and licences are registered and verified under your control. Knowledge transfer, the closing window, runs in weeks 3-14 as sessions with the outgoing team, front-loaded because their staff leave first. Docs and tests, AI-augmented, run in weeks 5-20, producing runbooks and a regression suite generated from the estate as it actually is. Shadow support, with the incumbent as backstop, runs in weeks 9-18, taking live tickets in parallel so every handover gap surfaces while help remains. Full ownership, covering the SLA and roadmap and highlighted, starts with the SLA handover in weeks 11-18, with escalation paths rehearsed, and is complete from week 19 to week 24.

Four phases, shaped around your exit dates

The durations below are typical. A planned wind-down with a long runway is an advantage, and we structure the phases against your notice period rather than to a fixed template.

  1. Estate assessment

    2-4 weeks

    Before any commitment on either side, we establish what the estate actually contains. This runs whether or not the outgoing partner is involved.

    • Codebase, architecture, and dependency review
    • Infrastructure, hosting, and cost review
    • Security posture, disaster recovery, and backup verification
    • An inventory of integrations, devices, and third-party dependencies
    • A risk register, ranked, with the items that need attention first

    You own the output. It is useful to you regardless of who you appoint.

  2. Knowledge transfer

    4-12 weeks

    The window when the outgoing team is still available is the most valuable asset in the whole transition, and it closes. We work to a written transfer plan with named topics, named people, and a completion checklist.

    • Recorded walkthroughs of each subsystem
    • Deployment and release procedures, performed rather than described
    • Known issues, workarounds, and deliberate technical debt
    • Business context behind the decisions that look odd from the code

    Where availability is limited, we fall back on codebase analysis. It takes longer and it is second best, so we front-load the sessions that only people can give us.

  3. Shadow support

    4-12 weeks

    We take live tickets alongside the incumbent while they still hold formal responsibility. This is where an orderly transition earns its keep. Every gap in the handover surfaces while there is still someone to ask.

    • Shadow support on real incidents, with the incumbent as backstop
    • Monitoring, alerting, and runbooks stood up under our operation
    • First changes shipped through our own pipeline
    • SLA, escalation paths, and reporting cadence agreed and rehearsed

  4. Full ownership

    We hold the SLA. The outgoing partner can leave with nothing outstanding.

    Named team who know the estate, available to your people directly rather than through a queue.

    Agreed coverage matched to your operating pattern, including cover outside office hours where the business runs outside office hours.

    Monthly reporting on incidents, system health, security posture, and progress against the risk register from Phase One.

    Quarterly roadmap reviews where modernisation, reporting, and improvement work is planned rather than squeezed in.

Built in transition, kept current

What transition produces becomes how we run your system

The knowledge base, runbooks, and scorecard are not handover paperwork. Our engineers and AI tools work from them every day, and every incident and release updates them.

Four phases from transition to running your system: knowledge transfer, stabilisation, takeover, continuous improvement
A four-phase cascading process showing how what transition produces becomes how we run your system. Phase 1, discovery and knowledge transfer with read-only access: AI drafts journeys, implementation notes, and known issues from source and work-item history, engineers and the outgoing team review them, and the readiness scorecard sets the baseline. Phase 2, stabilisation of pipelines, the QA gate, and monitoring: build and release pipelines are restored with a human QA gate, Application Insights and error tracking are connected, and runbooks are tested against real alerts. Phase 3, operational takeover, highlighted, where we hold the SLA: first and second line work from runbooks and known issues for each critical function, and our support rota runs from a daily AI brief, with engineers confirming every finding. Phase 4, continuous improvement, kept current month after month: every incident close-out and release updates the knowledge base, and monthly service reports track progress against the scorecard baseline and feed the roadmap.
Quality assurance

A named tester signs off every release

From planned changes to emergency fixes. An urgent fix gets a shortened test plan, never a skipped one.

Release sign-off: AI drafts the test plan and runs checks, engineers test and approve, then release through your pipelines
A swimlane showing who does what in a release, across three lanes: AI, engineers, and your team. Stage 1, test plan: AI drafts it from documented workflows and callers. Stage 2, automated checks: AI runs unit, integration, and critical-path regression. Stage 3, human QA, highlighted: engineers carry out exploratory testing on the changed journeys. A sign-off gate follows. Stage 4, approval: a named engineer approves, through your change process. Stage 5, release: AI checks the release against the evidence, and engineers deploy through your pipelines, with evidence stored.
Who does what

AI does the legwork. Engineers decide.

Our senior engineers stay responsible for every decision. AI helps them get to the evidence faster.

Who does what in support: AI does the legwork and engineers decide across seven activities, from evidence to reporting
A responsibility matrix for seven support activities, showing where AI does the legwork and where engineers decide. Evidence: AI gathers telemetry, logs, releases, and similar past tickets, and engineers check the evidence is complete and relevant. Diagnosis: AI suggests likely causes, ranked, with supporting data, and engineers confirm the root cause. Priority: AI proposes urgency based on the trend, and engineers set priority with your IT team. Change: AI drafts code, tests, and release notes, and engineers review and approve the change. Testing: AI drafts test cases and runs automated checks, and human QA signs off every release. Release: AI checks the release against the evidence, and engineers deploy through your pipelines. Reporting: AI drafts incident notes and report sections, and engineers own the conversation with you.

Investigation uses read-only access. Write access stays with named engineers. Personal data is stripped from telemetry before it is stored, and we only use AI services whose commercial terms exclude training on client data, within our ISO 27001 controls.

Your team

Who takes ownership

A permanent, UK-based team. The same people who learn the estate during transition are the people who support it afterwards.

S

Solution Architect

Leads the estate assessment and owns the target architecture. Decides what is inherited as-is, what is stabilised, and what is modernised, and in what order.

S

Senior Software Engineers

Run knowledge transfer with the outgoing team. One named engineer becomes the standing technical authority on your systems and leads every significant change after handover. The team also owns Azure infrastructure, CI/CD pipelines, monitoring, and disaster recovery, and verifies that backups restore and failover works.

Q

QA Analyst

Builds the automated regression coverage that most inherited estates lack, starting with the paths where a failure would stop the business.

D

Delivery Manager

Your point of contact throughout. Runs the transfer plan, tracks the checklist to completion, reports progress, and chairs the quarterly reviews.

"The team are experienced, practical, people who quickly cut to the important issues."

Colin Waggett

CEO, Third Space

Seen enough? Let's talk through your requirements.

Book a free consultation
FAQ

Frequently asked questions

How is this different from an internal systems handover?

An internal systems handover covers systems leaving an in-house team. A development partner transition covers systems leaving another supplier. The difference matters commercially: there is a contract to exit, an exit plan to agree, intellectual property and access to transfer, and often a competitive selection process before any of it starts.

How do you use AI during a transition?

AI reads the whole estate: every repository, stored procedure, and work item. It drafts user journeys, implementation notes, and a known-issues register for each critical function. Our engineers and the outgoing team review everything before it is published to you. Our guide on how to change application support supplier covers the full approach.

Does AI get access to our production data?

AI works from metrics, error summaries, code, and tickets. Personal data is stripped from telemetry before it is stored. Investigation uses read-only access, and we only use AI services whose commercial terms exclude training on client data, within our ISO 27001 controls.

When should we start looking for a replacement partner?

As soon as a wind-down is credible, not when notice is served. The most valuable phase of a transition is knowledge transfer from the outgoing team, and that window shrinks as their staff leave. Starting early also means you select on fit rather than on availability.

What if the outgoing partner will not cooperate?

We handle both cases. Where a partner is cooperative, and most planned wind-downs are, we get a materially better transition. Where they are not, we reconstruct the estate from code, infrastructure, and observed behaviour using AI-augmented analysis. It takes longer and costs more, so we plan for it explicitly rather than hoping.

Can you take on the Azure infrastructure as well as the application?

Yes. We are a Microsoft Solutions Partner for Azure Infrastructure and for DevOps and GitHub, and we hold ISO 27001 and Cyber Essentials Plus. Many estates that moved to Azure were migrated by a partner without deep cloud expertise, so infrastructure, cost, and disaster recovery are usually where the early wins are.

Do you handle transitions that run over more than a year?

Yes. Planned wind-downs commonly run 12 to 24 months from first notice to final exit. A long runway is an advantage, because knowledge transfer and shadow support can be spread out and done properly. We structure the phases against your exit dates rather than to a fixed template.

We are running a tender. Can you take part?

Yes, and we would rather you ran one. A structured selection gives you comparable answers and gives us a clear brief. Our guide to tendering for a long-term technology partner sets out the evaluation criteria that separate suppliers on this kind of work.

Will you modernise the estate as well as support it?

Yes, but not first. We stabilise, document, and take operational control before proposing change. Once the estate is understood, modernisation runs through the same agreement, whether that is legacy modernisation, reporting and data work, or user experience improvements.

Related

Where to go next

Choosing a long-term technology partner

The evaluation criteria and tender structure for selecting a partner to own an estate.

Managed Application Support

Coverage models, SLA structure, and what ongoing support includes.

How to change application support supplier

Exit planning, knowledge capture, stabilisation, and a clean takeover.

Maintainability Review

An independent read on codebase health before you commit to a supplier.

Daily AI operations brief

How AI turns overnight telemetry and tickets into a morning brief, checked by an engineer.

Your development team left

A practical guide to what happens next when a vendor or team disappears.
AI insights

See how AI is changing how we build software

Our quarterly AI Velocity Report tracks real delivery metrics from live projects: how much of our code is AI-authored, how delivery timelines compare to baseline, and which tools are making a measurable difference. No marketing spin, just honest data from a team that builds software every day.

Read the latest AI Velocity Report
Get started

Start before the notice lands

The knowledge you can transfer from an outgoing partner shrinks every month. Book a free consultation and we will talk through your estate, your exit timeline, and what a structured transition would involve.

Book a free consultation

or call 01202 006729