The beautiful tip of the iceberg
Most of what we build you'll never see. This is the part you can.
- Below the surfaceSaaS platforms, cloud systems and the engineering businesses run on.
- Above itA small glimpse of our UI/UX craft — ten real product interfaces.
- Home
- Services
- Managed Support
- Development Partner Transition
Your development partner is winding down. Your systems still have to run.
When an incumbent supplier plans an exit, you need more than a replacement development team. You need an organisation that can understand an existing estate, take operational ownership, improve its resilience and security, and develop the platform with your stakeholders over the long term. We run that transition as a structured programme: knowledge transfer while the outgoing team is still available, parallel running under overlapping SLAs, then full ownership.
Four reasons a partner transition starts
Only one of them is a failure. All four need the same discipline.
The partner is winding down
They are closing development operations, being acquired, or exiting your sector. There is a date, and everything must be transferred before it.
The relationship has stalled
Nothing has broken, but nothing is moving either. The roadmap slips, the same issues recur, and the platform is no longer improving.
The estate has outgrown them
Cloud architecture, integrations, security expectations, or device estates now exceed what the incumbent can credibly deliver.
Concentration risk
One supplier holds the code, the keys, and the knowledge. The board has noticed, and the auditors will.
What a long-term technology partner has to bring
Organisations replacing an incumbent usually write a list very like this one. It is the combination that matters: ownership of an established Microsoft estate, in one team, with clear separation between development and operational control.
C# / .NET application development & support
Defects, enhancements, and new features across .NET, ASP.NET Core, Blazor, and .NET Framework codebases we did not write.
Microsoft Azure architecture & management
Subscription governance, landing zones, App Service and Container Apps, Azure SQL, Key Vault, Front Door, and monthly cost control. Our Azure practice.
Application maintenance & modernisation
Stabilise first, then modernise release by release. Legacy .NET upgrades and cloud modernisation with the same team, no second discovery.
Azure DevOps / CI/CD
Automated build, test, and deployment pipelines with quality gates, environment parity, and blue/green or canary releases. No manual deployments, ever. Azure DevOps services.
API & systems integration
REST, GraphQL, SignalR, message queues, and third-party platforms such as Xero, QuickBooks, Stripe, and Dynamics inventoried, monitored, and extended. See our integration work.
Database & data-platform support
SQL Server, Azure SQL, Cosmos DB, and PostgreSQL: performance tuning, schema change management, backup and point-in-time restore verification, and reporting platforms.
Cyber security, technical assurance & DR
OWASP-aligned reviews, dependency scanning, penetration testing, and a documented disaster recovery plan with tested restores and agreed RTO/RPO. Cyber Essentials certified. Trust Centre.
Monitoring, incident & problem management
Application Insights and Azure Monitor with agreed alerting and escalation. Incidents restore service; problems remove causes. Reported separately every month.
Technical architecture & roadmap
A named architect owns the target architecture and a living roadmap, reviewed quarterly with your stakeholders. Written with CTOs and technical leaders in mind.
Ongoing feature development & continuous improvement
Sprint-based delivery by the same engineers who support the platform, with weekly staging releases and code review on every change.
Collaborative by design
We work alongside your internal product owners, IT, security, and leadership, with daily visibility, monthly service reviews, and quarterly roadmap sessions. Our ways of working are published in the Client Playbook.
Six things that must move, and how we move them
Knowledge
Structured, recorded sessions with the outgoing team capturing architecture decisions, deployment quirks, undocumented workarounds, and the business context behind them.
Access & control
Source control, Azure subscriptions, DNS, certificates, secrets, and app store accounts transferred into your ownership, with a verification register signed off item by item.
Documentation
AI-augmented analysis of the codebase generates architecture maps, data flows, and API specifications in days. Senior engineers verify and complete them.
Regression suite
Automated tests built around the highest-risk paths first, so we can change the system with confidence before we know every corner of it.
Operational ownership
Monitoring, alerting, incident and problem management, and a defined SLA. Rehearsed during parallel running, not improvised on day one.
Roadmap
Once stabilised, a modernisation and improvement plan agreed with your stakeholders, so the platform moves forward rather than merely surviving the handover.
Phases overlap on purpose
Knowledge transfer is front-loaded while the outgoing team is available. Shadow support starts before the SLA moves. Timings flex to your partner's actual exit date, whether that is six months or eighteen.
Illustrative. Every transition is planned against the outgoing partner's real exit date and the size of the estate.
Four phases to full ownership
Estate assessment
Codebase and architecture review, infrastructure and cost analysis, security posture and backup verification, integration and dependency inventory.
Knowledge transfer
Recorded subsystem walkthroughs, live demonstration of deployment procedures, documentation of known issues and workarounds, and the business reasons behind the architecture.
Parallel running
Shadow support on live incidents alongside the outgoing team. Monitoring and alerting stood up. First pipeline changes made. SLA and escalation rehearsed.
Full ownership
SLA assumed. Named permanent team directly available to yours. Monthly incident and health reporting. Quarterly roadmap reviews with your stakeholders.
Five permanent, UK-based roles
Nobody offshore, nobody rotating. The people who receive the knowledge are the people who keep it.
Technical architect
Leads the estate assessment and owns the target architecture and roadmap.
Lead engineer
The authority on your systems after handover; leads every change.
DevOps engineer
Owns infrastructure, CI/CD, monitoring, backups, and disaster recovery.
QA analyst
Builds regression coverage starting with the paths that would hurt most.
Delivery manager
Your point of contact; runs the transfer plan and the monthly service review.
An initial discussion on capability and fit
Most organisations approach us before they can share detail. That is the right order, and it is how we expect to begin.
Capability & fit conversation
A candid discussion of what you are responsible for, what the incumbent provides today, and whether we are the right shape of partner. Our credentials, policies, and case studies are all public.
Confidentiality in place
A mutual NDA, yours or ours, so that further information about the estate, contracts, and exit timeline can be shared appropriately. We can also participate in a formal tender if that is your route.
Estate assessment & proposal
The assessment phase above, ending in a ranked risk register, a transition plan against the real exit date, and a support proposal with SLA tiers and costs.
Explore the managed support family
Every engagement starts from the same foundation: understand the estate, take operational ownership, then improve it. These pages cover the situations we are asked about most.
Development Partner Transition
A structured takeover of an established Microsoft estate when your incumbent supplier is winding down.
Due diligence, already answered
Handing a live system to a new partner means trusting them with source code, credentials, and data. We make that easy to verify: our policies, certifications, and evidence are published openly in our Trust Centre, and the commercial terms we work to are set out in our Client Playbook.
Trust Centre
Our complete policy set, certifications including Cyber Essentials, insurance, and company information in one place.
Visit the Trust CentreInformation Security
How we protect your code, credentials, and data during an engagement: secrets in Key Vault, encrypted transfers, least privilege.
Read the policyIncident Response
How a security incident would be handled: containment, investigation, and prompt notification of affected customers.
See how we respondHosting & Data Residency
Where your data lives while we support the system, and how UK residency is maintained when your obligations require it.
Check data residencyEngagements are governed by our Master Services Agreement, with a UK GDPR Article 28 Data Processing Agreement wherever personal data is involved. We are happy to sign a mutual NDA before any access is granted. Common due-diligence questions, answered →
Partner transitions, answered
How is this different from an internal systems handover?
A partner transition involves a contract exit, transfer of intellectual property and accounts, and usually a supplier selection process. An internal handover does not: the knowledge is leaving with a person rather than a company, and the systems are already yours.
When should we start looking for a replacement partner?
As soon as the wind-down is credible, even if the exit is a year or more away. The knowledge transfer window is only open while the outgoing team is still employed and cooperative, and it is the single biggest determinant of how smooth the transition is.
What if the outgoing partner will not cooperate?
We reconstruct the estate from what you hold: source code, infrastructure, and production behaviour, using AI-augmented analysis verified by senior engineers. It takes longer and costs more than a cooperative transfer, but it is routine for us, and the maintainability review is built for exactly this.
Can you take over the Azure infrastructure as well as the applications?
Yes. We are a Microsoft Partner with deep Azure and Azure DevOps expertise and hold Cyber Essentials certification. Where you already have an IT provider or infrastructure security partner, we coordinate with them and keep developer access and security administration strictly separate, as set out in our Client Playbook.
Can a transition run longer than twelve months?
Yes. The roadmap above is illustrative. We plan against the incumbent's actual exit date and the size of the estate, whether that means six months or eighteen, and we run overlapping SLAs for as long as the parallel period requires.
Will you participate in a formal tender?
Yes. We respond to RFIs, RFPs, and framework mini-competitions, and we are happy to begin with an informal capability discussion first so that both sides know whether a tender response is worthwhile.
Can modernisation happen during the transition?
Stabilisation comes first: we do not change architecture while ownership is still moving. Once the SLA has transferred and the regression suite exists, modernisation is planned into the quarterly roadmap and delivered by the same team. See legacy .NET migration and cloud modernisation.
Who owns the estate assessment if we choose another supplier?
You do. The risk register and transition plan are yours regardless of who you appoint. Bespoke deliverables are assigned to you on payment, and we retain no lock-in of any kind.
Start with a conversation about capability and fit
If your partner has signalled a wind-down, the knowledge transfer window is already open and already closing. An initial discussion costs nothing, commits you to nothing, and can happen under NDA from the first call.
Book an Initial Discussion All Managed Support ServicesCyber Essentials certified · UK-based team · Microsoft Partner · Policies and evidence at our Trust Centre
Start a meaningful conversation with us today.
Assemblysoft are Your Safe Pair of Hands
Azure
Azure DevOps
