Before you decide whether to renew or replace your managed IT provider, collect the information needed for either choice. That includes the services you are buying, the systems involved, the access your organization controls, and the work required if another provider takes over.
This checklist starts before renewal, then follows the handover through discovery, cutover and validation. It is a planning tool: your IT lead and the providers involved need to adapt it to your environment and agreement.
What is an MSP transition?
An MSP transition transfers agreed IT service responsibilities from one provider to another. It can involve documentation, user support, monitoring, administrative access, licensing arrangements and backup services. Some transitions also include changes to tools or infrastructure; identify those separately so they have their own plans.
There is no single timetable that fits every transition. Notice terms, system complexity, documentation quality, access and the work being transferred all affect the schedule. Agree milestones and acceptance checks before committing to a cutover date.
Before renewal: what to request from your current provider
Review the agreement early enough to understand renewal and notice dates. Request the records below whether you intend to stay or leave. You can also use this list during regular service reviews rather than waiting for renewal.
- Contract and notice dates. Confirm whether the agreement has a fixed term or automatic renewal, the relevant dates, and the notice and offboarding provisions. Ask your organization’s contract owner to resolve anything unclear.
- Asset inventory. Request the systems the provider manages, their owners, and the available lifecycle and warranty information. Compare the list with records held by your team and sites.
- License inventory. List subscriptions managed or billed by the provider, quantities, renewal dates and the associated agreements. Identify the customer organization and billing relationship for each.
- Administrative access. Ask your IT lead to verify how your organization retains appropriate administrative control of each platform and what access is delegated to the provider. Record any gaps and agree how to address them securely.
- Network diagrams and documentation. Request current diagrams, configuration records and runbooks for your environment, with dates and a named contact for questions.
- Ticket and SLA reports. Review service performance over an agreed period, including response and resolution measures, recurring issues and unresolved requests.
- Backup and recovery evidence. Confirm which systems are covered, who operates the backups, how access is controlled, and what restore testing has been completed. Record the results and any known recovery limitations.
- Transition responsibilities. Establish what the agreement provides for documentation, access, tooling and support when the relationship ends. Do not assume every service or record transfers in the same way.
If you decide to stay
Use the findings to make the renewal discussion specific. Missing documentation, unclear responsibility for a system, or a recurring service issue each needs an owner and an agreed action.
Ask how progress will be reviewed. A responsibility matrix can help distinguish work the provider owns from work retained internally or assigned to another vendor.
If you decide to leave
Use the same records to brief potential providers and define the handover. Ask the incoming provider to identify anything it still needs before it can price the work or commit to a transition plan.
Keep unresolved items visible. An incomplete inventory or an uncertain license arrangement is a task to investigate, not a detail to leave until cutover.
Before giving notice: confirm control and dependencies
Check these areas with your IT and contract owners before choosing the transition date:
| Area | What to establish |
|---|---|
| Platform access | The administrative control your organization needs, delegated provider permissions, and the process for changing access |
| Domains and DNS | Account ownership, authorized contacts and how required changes will be made |
| Licensing and billing | Subscription terms, renewal dates, transfer eligibility and any required cooperation between parties |
| Backups | Data and configuration access, recovery arrangements, retention requirements and the impact of ending the existing service |
| Provider-owned tools | Which monitoring, security, management or backup tools will be removed or replaced, and what continuity checks are needed |
| Agreement | Notice and offboarding requirements, charges, responsibilities and any limits on transition assistance |
A Microsoft licensing change should be reviewed with the relevant licensing partners before dates are promised. Confirm the applicable subscription arrangements and required steps; do not assume that every change is a routine billing transfer.
If the project also involves a merger or tenant consolidation, keep that work visible as a separate dependency. Our Microsoft 365 tenant migration planning guide covers the planning questions for that work.
What should the incumbent hand over?
Turn the agreed requirements into a handover register. For each item, record who supplies it, who receives it, the due date and how the receiving team will verify it.
The register may include:
- Network diagrams, configuration records and asset inventories.
- Runbooks and knowledge articles relevant to the supported environment.
- Vendor contacts, support arrangements and authorized account contacts.
- Ticket history and unresolved issues for an agreed period.
- Backup configuration and restore-test records.
- Licensing records and the status of any changes in progress.
- Access-transfer tasks, with a secure method agreed by the IT owners.
Avoid distributing credentials in ordinary spreadsheets or email. Have the responsible IT teams agree a secure transfer and access-change process for each system.
Ticket history gives the incoming service desk context about recurring issues and previous fixes. Confirm what can be exported, how it will be transferred and what information should be retained or restricted.
Agree the overlap and support responsibilities
Decide whether a period of overlapping service is needed and what each party will do during it. Agree its duration, cost and responsibilities rather than assuming that paying two providers means both cover everything.
The plan should answer:
- Who handles user requests and incidents on each date?
- Who may make changes, and how are conflicting changes prevented?
- Which tools remain active, which change, and who validates their configuration?
- What access and documentation does the incoming team still need?
- How will support routes, critical systems and recovery arrangements be tested?
- Who decides that the incoming provider is ready to accept responsibility?
Where a parallel run or supervised support is practical, agree its scope and acceptance checks. Record alternatives when the existing contract or environment does not allow it.
Plan the cutover and validation
The cutover plan should list the changes, owners, sequence, checks and escalation contacts. Include support numbers, ticket routing, monitoring, provider accounts, tools and any linked licensing or backup changes.
Have the IT and security owners agree access changes for each stage. Verify that the incoming arrangements work while avoiding unnecessary continued access for the outgoing provider. The correct timing depends on the systems, risks and transition design; there is no universal rule that revocation must always happen last.
Plan for service continuity, but do not assume downtime is impossible. Tool replacement, configuration changes, access problems or dependencies outside the provider’s control can affect the transition. Document any expected maintenance, user communications and recovery or rollback options.
Before closing the handover, verify that:
- Users can reach the correct support team.
- Agreed monitoring and ticket routing work.
- Required access is available and obsolete access has been addressed.
- Documentation and unresolved issues have named owners.
- Backup and recovery arrangements have been checked by the responsible team.
- The customer and providers have recorded acceptance or outstanding exceptions.
When switching may not solve the problem
A change of provider will not by itself resolve an unclear service scope, missing internal ownership or work that was never funded.
If you have a capable internal team but need additional coverage, consider whether a co-managed arrangement addresses the gap. If the problem is still difficult to define, an IT maturity assessment may help clarify priorities before you request proposals.
Common questions
What should we request before renewal if we plan to stay? Start with the service scope, asset and license records, access arrangements, performance reports and backup evidence. Use missing or unclear information to agree improvements and review dates. Documentation alone does not establish that service is good; consider it alongside actual performance.
How long does it take to switch MSPs? Build the timetable around your notice requirements, scope, dependencies and acceptance checks. Ask the incoming provider for a proposed plan and the assumptions behind it. Changes to tools, licensing or infrastructure may require additional work.
Can a provider switch be completed without downtime? Maintaining service is the aim, but the risk depends on the changes involved. Ask for the planned tests, maintenance windows, contingency arrangements and communication process. Do not treat a no-downtime statement as a substitute for that plan.
What if the current provider does not cooperate? Document the missing items and involve your IT and contract owners. Confirm what your organization controls, what assistance is required and what the agreement says. Escalate contractual disputes through the appropriate advisers rather than assuming administrative access solves every handover dependency.
Do we have to move our Microsoft licenses? That depends on how the licenses are purchased and managed, and on the proposed new arrangement. Ask the relevant licensing partners to confirm what needs to change, the applicable terms and the steps required before setting a date.
Discuss your next support arrangement
Considering a change? Contact Virteva with your current support scope, key dates and the problems you need to resolve. You can also review our managed IT services or Minnesota managed IT offering before the conversation.
