Reviewing an MSP contract or switching IT providers can feel risky because the outgoing company may manage passwords, licenses, backups, security tools, and equipment the business depends on every day.
A well-written managed service agreement should reduce that risk. It should explain what the provider owns, what the client owns, how the relationship can end and what each party must do during the transition.
The best time to review those terms is before signing. The second-best time is before announcing a change.
Before evaluating contract language, make sure the service model itself fits the business. Start with what an MSP is and when managed IT makes sense.
Do MSPs require long-term contracts?
Some providers offer month-to-month service. Others use one-, two- or three-year terms. Either arrangement can be reasonable when the obligations are clear.
A longer term may help the provider recover onboarding costs, reserve capacity or offer more predictable pricing. A shorter term gives the client flexibility. Neither one guarantees good service.
2Labs does not require long-term contracts for its standard managed services. Whatever provider you consider, ask for the actual agreement rather than relying on a verbal summary.
What should an MSP contract include?
The exact service scope
The agreement should identify the supported users, devices, locations and systems. It should also explain which services are included, billed separately or excluded.
Review helpdesk hours, on-site work, after-hours support, monitoring, updates, security tools, backups, cloud administration, projects and strategic planning.
Our draft guide What Should Managed IT Services Include? provides a fuller comparison list. Replace this local link with the public URL after publication.
Response and escalation expectations
Look for priority definitions, response targets, emergency contact methods and escalation procedures. Confirm whether “response” means an automated acknowledgement or contact from a technician.
See MSP Response Times and SLAs for a practical breakdown. Replace the draft link after publication.
Pricing and changes
The agreement should explain:
- The monthly fee and billing date
- One-time onboarding charges
- Included and separately billed work
- License and equipment costs
- Travel or on-site charges
- After-hours rates
- How pricing changes when users, devices or locations change
- Renewal increases or notice requirements
Ask whether third-party licenses are portable if you leave or whether they must be replaced.
Account and data ownership
The business should own its domains, primary cloud tenants, data and core vendor accounts. The MSP can receive delegated administrative access without becoming the owner.
Be cautious if a provider wants to register the business’s domain, Microsoft 365 tenant or essential licenses under an account the client cannot access.
Security and confidentiality
Review how remote access, privileged accounts, client documentation and security incidents are handled. The contract should describe notification and cooperation expectations without making unrealistic guarantees.
Term, renewal and cancellation
Check:
- Initial contract length
- Automatic renewal language
- Required cancellation notice
- Early termination charges
- Whether termination rights differ for each party
- What happens after repeated service failures
- How prepaid amounts or equipment leases are handled
A cancellation clause that exists only in theory is not useful. The notice address and method should be practical and current.
Transition assistance
The agreement should address return of documentation, removal of access, license transfers, equipment ownership and reasonable cooperation with a replacement provider.
If transition labor is billable, the rate should be known in advance.
Red flags in an MSP agreement
Pause before signing if:
- The scope relies on vague phrases such as “all IT support” without definitions
- Important security or backup responsibilities are only verbal
- The provider owns the client’s domain or primary cloud account
- Cancellation requires an unusually narrow method or window
- Automatic renewal is easy to miss
- The client cannot retrieve documentation and credentials
- Pricing can change without meaningful notice
- The agreement disclaims every responsibility while marketing promises comprehensive protection
- There is no transition process
- The provider discourages legal review or refuses reasonable questions
A contract is not a substitute for trust, but trust is not a substitute for a contract either.
How to prepare before switching IT providers
Do not begin by asking the outgoing provider to disconnect everything. Begin with an inventory and transition plan.
1. Review the current agreement
Confirm the renewal date, cancellation notice, outstanding projects, equipment leases, software commitments and transition fees. If the terms are unclear or the stakes are substantial, have qualified counsel review them.
2. Identify business-owned accounts
Inventory:
- Domain registrar and DNS
- Microsoft 365 or Google Workspace
- Internet and phone providers
- Backup services
- Security products
- Line-of-business software
- Website hosting
- Network and firewall management
- Hardware warranties and vendor portals
Verify that the business has an owner-level account and current recovery information where appropriate.
3. Build an equipment and software inventory
List computers, servers, network devices, printers, security cameras and important applications. Record ownership, age, warranty and location.
4. Preserve documentation
Request current network diagrams, device lists, vendor contacts, backup information, license records and open-project notes. Passwords should move through a secure method, not an ordinary email attachment.
5. Verify backups before major changes
Confirm what is protected, whether recent jobs succeeded and when restoration was last tested. Do not assume the incoming provider can repair an undocumented backup after access has been removed.
6. Establish a communication plan
Choose one authorized contact for the outgoing provider and one for the incoming provider. Tell employees when the support contact changes and how to report problems during the transition.
7. Coordinate access changes
The incoming provider may need temporary access before the outgoing provider is removed. Schedule the handoff so security tools, monitoring and support do not disappear for days between contracts.
After the transition, remove old technician accounts, rotate shared or recovery credentials where needed, review privileged access and verify that the outgoing provider no longer receives alerts or client data.
How do you switch from in-house IT to an MSP?
The same continuity principles apply, but the process should preserve an employee’s institutional knowledge respectfully.
Document systems, vendors, recurring problems, project history and business-specific procedures. Whenever possible, allow an overlap period. Avoid framing the transition as an investigation unless there is a genuine security or conduct concern.
The incoming MSP should verify the environment rather than assuming every note is complete. The business should also decide which strategic or application responsibilities remain internal.
What should the new provider verify on day one?
The incoming provider should confirm:
- Administrative ownership and access
- Supported users, devices and locations
- Security and monitoring coverage
- Backup status and recovery contacts
- Internet, phone and software vendors
- Open incidents and planned projects
- Unsupported or high-risk systems
- Employee support instructions
- Emergency escalation contacts
A good onboarding process produces a prioritized baseline: what is working, what needs immediate attention and what can wait.
Avoid turning the transition into a hostage negotiation
Most provider changes can remain professional. Give the required notice, pay legitimate final invoices and make specific requests for business-owned information.
The outgoing provider should not withhold client-owned accounts or data to punish a departure. The incoming provider should not make unsupported accusations merely to justify the sale.
2Labs’ article You Already Have an IT Company. So Why Do You Feel Like You’re On Your Own? can help determine whether the issue is a correctable communication problem or a genuine reason to change.
Related MSP guides
- Understand response times and service-level agreements
- Measure an MSP with a practical quarterly scorecard
- Prepare for an MSP consultation
If you are considering a switch, a Practical Tech Checkup can inventory the environment and identify transition risks before access starts moving. The goal is continuity—not drama, however much IT occasionally auditions for it.