Changing IT provider: the questions to settle before the switchover.
A transition is prepared well before the first ticket goes to the new support team. This checklist helps you gather the information and allocate decisions. It does not replace reading the contracts or a technical plan suited to your environment.
1. Define what is really changing.
Write the goal of the change in one sentence: taking over support, changing hosting, coordinating suppliers better or gaining a specific skill. Then list the services affected and those that stay in place.
For each service, record its name, the supplier, the internal owner, the scope being transferred and any points still unknown. This first list stops you assuming that everything depends on a single contract.
2. Gather the contracts and check who holds them.
Collect the documents available for licences, internet access, telephony, hosting, domain names and equipment. Identify the contract holders, the end dates and the exit terms to be checked.
Do not cancel a service simply because a takeover date has been discussed. Dependencies between services and contract terms must be examined by the relevant people.
3. Ask for the documentation you need.
Prepare an inventory of workstations, servers and network equipment, then of applications and contacts. Add existing diagrams, procedures and any monitoring records available.
Missing information is not a detail to hide: add it to a list of gaps, with someone responsible for clarifying it. It is better to know that something is still unknown than to assume it has been taken over.
4. Organise access without exposing it.
List the rights needed and the people who can authorise their transfer. Login details and secrets must not be placed in an unprotected shared spreadsheet or in a public form. The channel, the recipients and the confirmation of receipt are agreed with the parties involved.
Also plan a review of access rights after the transition. The technical details of this operation will depend on your environment and the responsibilities agreed.
5. Define how you will know the takeover works.
Choose representative tasks with your teams: logging in, opening the business application, finding a file, receiving a call, asking for help. For each test, note who signs it off and the expected result.
Tests must be prepared without running any destructive operation. Any change likely to disrupt the business needs a suitable schedule and authorisation.
6. Prepare your staff.
Share the planned date, what changes and what stays the same. Give the new point of contact, the information to provide with a request and the internal contact if in doubt. Do not promise a resolution time that is not included in the chosen offer.
7. Review things after the switchover.
Gather the requests still open, the missing documents and the differences observed. Assign an owner to each follow-up action. The transition is not the moment to launch every modernisation project automatically: stabilise the new way of working, then prioritise improvements.
Your preparation sheet.
Goal of the change: to be filled in by your team.
Services transferred and retained: to be listed.
Contracts and end dates checked: to be confirmed.
Documentation and access: owners assigned.
Takeover tests: tasks and approvers identified.
Communication: message and date prepared.
Follow-up review: participants and topics planned.
Would you like to turn this list into a handover plan? Skill Group can help you define the steps and the scope of the takeover.
Your questions
Is this checklist enough to decide on cancelling contracts?
No. Contracts and dependencies need to be examined. This checklist does not trigger any cancellation.
Should I wait until I have all the answers before contacting you?
No. Missing information can be part of the scoping.
Further reading
Got a digital issue? You don’t have to work out who should handle it.
Describe your situation in your own words. The Skill Group team will get back to you to talk it through.