Your current IT provider’s last day shouldn’t be the first day your replacement team discovers how the business works. For UK SMEs, switching IT support providers needs careful coordination, clear ownership and a tested fallback plan.
You can reduce avoidable disruption by transferring knowledge and access before responsibility changes hands. However, a well-planned transition still needs room for unexpected problems.
If you’re managing the change as an owner, operations director or IT manager, start with the contractual dates and account access.
Prepare for switching IT support providers before giving notice
Set the boundaries of the transition before announcing an end date. The incoming team needs enough time to understand your systems and prepare.
Check the contract, notice period and handover duties
Read the existing agreement for notice dates, renewal terms, exit arrangements and agreed handover support. Identify which services continue until the contract ends and which need separate arrangements.
Support, software licensing, internet connectivity and backup services may have different end dates. Record these separately so cancelling support doesn’t accidentally interrupt another service.
Assign one named person within your organisation to manage the change. They should coordinate both providers, approve the schedule and resolve questions about responsibility. Give them a deputy for absences.
Also define what the replacement service will cover. Our managed IT support service guidance outlines responsibilities such as documentation and supplier coordination, which need clear ownership during the handover.
Confirm business ownership of systems and admin access
Administrator access and ownership are different. An engineer may manage Microsoft 365 without your business controlling the tenant’s recovery contacts or subscription arrangements.
Record the organisation associated with each domain, Microsoft 365 tenant, Microsoft Azure subscription, backup platform and software licence. Identify any service held through the outgoing provider’s account or supplied under its licensing arrangement.
Your business needs authorised contacts who can reach these services independently. Include domain registrar access, billing contacts, account recovery details and appropriate administrative roles.
Test that your authorised business contacts can sign in using their own accounts. Then establish how the incoming team will receive delegated access without making either provider the business’s only route into an essential system.
Build a complete IT handover before the new provider starts
A useful handover pack explains what exists, how it connects and who looks after it. Keep it accessible to your business and transfer sensitive information securely.
List devices, systems, suppliers and open support issues
Build an inventory covering laptops, servers, firewalls, network equipment, business applications and cloud services. Include software licences, renewal dates, supplier contacts and service accounts.
For each item, record its business owner, technical administrator and the location of its current documentation. Network diagrams should show connections between offices, remote workers and hosted systems.
Add unresolved support tickets, recurring faults and planned changes. An intermittent connection problem or scheduled accounting software upgrade shouldn’t become a surprise during onboarding.
Separate known problems from new transition issues. This helps the incoming team investigate correctly and prevents an existing fault from confusing acceptance checks. Date the records so engineers can distinguish current information from older configurations.
Check backups and recovery plans before changing responsibility
Establish what is backed up, where copies are stored and who can restore them. Include business data and the configuration information needed to rebuild essential services.
Record the latest successful recovery test, rather than relying only on a successful backup notification. The NCSC’s guidance on backing up data provides practical advice for small organisations.
Agree who monitors backup jobs and investigates failures throughout the transition. Responsibility must remain explicit whilst both teams have access.
Before a higher-risk change, documentBefore a higher-risk change, document the rollback steps, decision-maker and recovery dependencies. Agree alternative working arrangements and post-change testing with the incoming provider.ut sharing passwords by email
Use an approved business password manager or a controlled secure handover process. Never send passwords through ordinary email or place them in an unrestricted document.
Where possible, give engineers individual accounts with permissions appropriate to their tasks. Record who receives access, what they can administer and when that access starts.
Keep multi-factor authentication enabled throughout. Arrange authorised authentication methods for the replacement team rather than sharing one person’s authentication codes. The NCSC’s multi-factor authentication guidance addresses protection for corporate online services.
Also identify credentials used by automated processes. Changing a service account password without updating its dependent applications can interrupt scheduled tasks.
Stage the change to keep day-to-day work moving
A staged transition gives both providers clear responsibilities whilst your staff continue working. Plan around operational needs, including payroll and month-end deadlines.
Agree a staged onboarding plan with named owners
Set milestones for discovery, documentation review, access setup, monitoring and support transfer. Assign a named owner and escalation contact to each milestone.
A shared responsibility schedule should state who handles incidents during every stage. Avoid arrangements where both providers assume the other is investigating a failed backup or unavailable application.
Where possible, schedule higher-risk changes outside busy periods. However, an evening change still needs available decision-makers and staff who can test affected services.
Define rollback before work begins: what triggers it, who approves it and how the previous working configuration will be restored.
For businesses with several locations, our phased IT supFor businesses with several locations, consider starting with one office or support category before expanding. Avoid combining the handover with unnecessary infrastructure changes.a short message once the timetable and support routes are agreed. Explain the change date, how to report issues and any temporary instructions.
Include the new helpdesk email address or telephone number, along with an internal contact if those channels fail. Make the information available somewhere staff can reach without relying solely on email.
Tell managers how to escalate urgent problems affecting customers or essential work. They should know which provider is responsible at that point in the transition.
Explain any expected changes to remote support tools or sign-in prompts. Staff should know how to recognise authorised requests and report suspicious ones.
Finally, remind employees not to send passwords to engineers. Support instructions should preserve normal security precautions throughout the change.
Test the new IT support service and close the old access safely
A handover becomes complete when agreed responsibilities work in practice. Use recorded acceptance checks before closing the outgoing provider’s access.
Use acceptance checks to confirm the handover is working
Submit a test support request through each agreed channel. Confirm that it reaches the right team and follows the agreed escalation route.
Test essential business applications with representative users, including remote staff. Check that their permissions still allow normal work without granting unnecessary access.
The incoming provider should demonstrate that monitoring reaches its team and that backup alerts have an owner. Include a suitable recovery test within the acceptance plan.
Record each result, unresolved issue and responsible person. Agree when the incoming provider accepts each service responsibility, rather than treating the contract start date as proof that every system is ready.
Remove outgoing provider access only after checks are complete
Once replacement access works and essential services pass their checks, remove the outgoing provider’s permissions in a planned order.
Review administrator accounts, delegated cloud access, remote support tools and supplier portals. Include shared accounts and credentials stored in scripts or scheduled tasks.
Revoke obsolete permissions and rotate shared secrets through a controlled process. Keep MFA enabled, and test dependent services after credential changes.
Preserve required business records, including configuration documents and relevant support history. Transfer useful information into business-controlled storage before closing access to the old provider’s systems.
Finally, document what was removed, when it happened and who completed the work. Give any remaining temporary access an owner and an agreed expiry date.
Finish with a short transition checklist and quick answers
Use these final checks to close the transition:
- Record contract dates, handover duties and named business and provider owners.
- Establish business-controlled admin access and complete the asset, licence and supplier inventory.
- Test recovery arrangements, assign backup monitoring and transfer credentials securely.
- Agree staged onboarding, rollback decisions and clear staff support instructions.
- Complete acceptance checks, assign unresolved issues and remove obsolete provider access.
Keep the completed record alongside your system documentation. Outstanding actions should remain visible, with owners and deadlines, after routine support begins.
When should we notify staff? Once the change date and support routes are agreed, give staff enough time to understand the instructions. Send a brief reminder before the handover.
Should both providers overlap? An agreed overlap can support discovery, testing and incident handling. Its length depends on the environment and contract arrangements, with one clear owner for every service throughout.
When can old access be removed? After replacement access works and the relevant acceptance checks are complete. Close permissions in stages where dependencies require it, and record any temporary exceptions.
Keep the handover controlled until it’s complete
A carefully managed transition gives your business a clear owner for each service before support responsibility changes. Tested rollback steps also give you a practical response if a change causes problems.
Keep the handover plan active until acceptance checks, outstanding issues and access removal are documented. That discipline helps protect daily operations without assuming every change will run exactly as scheduled.
Contact us at Northern Star for help planning a carefully managed transition.
