1. Confirm authority and scope
Name the business decision-maker, read the current agreement and list the services that may transfer. Distinguish support responsibilities from separate broadband, phone, software, website and cloud contracts.
Practical transition guide
Change IT support provider without losing control of the business.
A support change is not automatically a wholesale technology migration. Done well, it is a controlled transfer of knowledge, responsibility and appropriate access—with working services protected throughout.
Start calmly
Prepare the business before turning the change into an emergency.
Businesses often postpone a support review because they fear losing passwords, upsetting a supplier or discovering that nobody knows how systems fit together. Those concerns are reasons to establish evidence and ownership—not reasons for a rushed confrontation.
Do not disable working services, rotate credentials or remove supplier access without an authorised and tested replacement. Follow contractual obligations and keep a clear decision record.
Six-stage transition
Move responsibility in a sequence the business can verify.
2. Build the evidence pack
Record what the business owns, who administers it and where evidence is missing. Gather account references and documentation without moving passwords or recovery codes into ordinary email or shared notes.
3. Agree the incoming responsibility
Define what the new provider will support, response arrangements, exclusions, third-party dependencies, access method and the work required before the support start date.
4. Plan a controlled handover
Set named contacts, dates and a secure route for documentation and credentials. Keep the outgoing provider involved for agreed questions and avoid disabling working access before replacements are proved.
5. Validate the transition
Test support contact routes, administrator access, monitoring, backup visibility, urgent escalation and telephone or broadband supplier contacts. Record unresolved items rather than assuming they transferred.
6. Review the first 30 days
Remove access that is no longer needed, close documentation gaps, confirm billing and licences, test a recovery action and agree the prioritised improvement plan with the business.
The handover register
Track the complete operating picture—not just computers and passwords.
For every area, record the business owner, current supplier, incoming responsibility, evidence received, secure access status and unresolved actions.
Business ownership
Authorised contacts, domains, cloud tenants, licences, warranties, contracts, renewals and notice periods.
Administrator access
Named administrative roles, supplier accounts, recovery ownership, multifactor authentication and emergency access arrangements.
Microsoft 365
Tenant details, users, licences, administrators, shared mailboxes, groups, forwarding, devices and third-party applications.
Network and connectivity
Sites, firewalls, switches, wireless access points, broadband circuits, addressing, remote access and support references.
Backups and continuity
Protected systems and data, destinations, retention, recent results, failure alerts, restore evidence and recovery dependencies.
Phones and communications
Numbers, routing, handsets, portals, call recording where used, supplier ownership and outage or diversion behaviour.
Websites and applications
Domain and DNS control, hosting, source repositories, deployment ownership, certificates, integrations and support contacts.
Open work and known issues
Outstanding faults, planned projects, temporary workarounds, end-of-life equipment, risks and commitments already made.
Questions for the incoming provider
Make the working relationship clear before the support start date.
- Exactly which services and locations are included—and which are not?
- Who owns each account, tenant, domain and administrative identity?
- How will privileged access be granted, protected, logged and later removed?
- What happens when the main support contact, broadband or phone service is unavailable?
- How are backup failures noticed, and what recovery has actually been tested?
- Which third parties are involved and who coordinates them during an incident?
- What documentation will the business retain if the relationship ends?
- What will be checked in the first 30 days, and who owns each resulting action?
A useful answer is specific
Look for named responsibilities, practical escalation routes and evidence that can be checked. A product list, vague promise or generic service level does not explain how your particular business will be supported.
Ask what the business will keep if the relationship later ends.
Transition-day controls
Validate new access before withdrawing old access.
- Confirm authorised business and supplier contacts
- Test the new support and urgent escalation routes
- Verify named administrative access and multifactor authentication
- Confirm monitoring, backup alerts and essential supplier portals
- Record open issues and anything still awaiting evidence
- Schedule removal of access no longer required
Avoid the common mistake
Do not treat receipt of a password list as a completed handover.
Access may be incomplete, shared, out of date or tied to somebody else’s recovery details. The incoming provider should prove necessary access, establish named administration where possible and record what remains unresolved.
Official guidance
Supplier access should remain limited, controlled and removable.
The NCSC’s supply-chain guidance says organisations should understand supplier risk, establish control and review access. Access that is no longer required should be removed, and responsibility for protecting important information cannot simply be transferred away.
Important boundary
This is practical technology and operational guidance, not legal, employment, regulatory, data-protection or contractual advice. Use appropriately qualified advisers for those questions.
Common questions
Change provider with realistic expectations.
Do we need to tell our current provider before preparing?
You can first review your own contracts, invoices, business records and ownership. Follow the agreement and obtain appropriate contractual or legal advice where needed before giving notice or requesting transition work.
Will changing provider cause downtime?
A well-planned support handover should minimise disruption, but no provider can promise that every unknown dependency will transfer without risk. Documented access, named contacts and staged validation reduce avoidable surprises.
Should the outgoing provider send all passwords by email?
No. Agree a secure transfer method for credentials and recovery information. Where possible, create new named access for the incoming provider and remove old access only after the replacement has been validated.
Do we have to replace every system at the same time?
Usually not. First establish control and support responsibility. Replacement work should be justified by evidence, business impact and sensible sequencing rather than bundled into the handover by default.
Can Oblyx work alongside the current provider?
Yes. Oblyx can carry out an independent Health Review, collect evidence and coordinate a transition while keeping capable existing suppliers involved where that is useful.
Is this legal or contractual advice?
No. This is practical technology and operational guidance. Contract interpretation, employment, data-protection and other legal questions should be taken to an appropriately qualified adviser.
Independent starting point
Establish the evidence before deciding what must change.
Oblyx can document the environment, clarify supplier ownership and build a prioritised transition plan without assuming every existing service needs replacement.