Switching IT Providers? A Transition Checklist for Law Firms

TRANSITION PLAYBOOK · SMALL US LAW FIRMS

A well-planned IT provider change should be almost invisible to the attorneys doing their work. Switching IT providers should not interrupt attorney workflows or weaken control of client information. Email should still arrive. Matter files should remain accessible. The firm should retain control of its accounts and data, and no technician should have to guess which company is responsible for an urgent problem.

When switching IT providers, the difficult part is usually not signing the new agreement. It is transferring operational knowledge and administrative access without creating a period when neither provider can support the firm—or when both retain unnecessary control. That handover deserves a plan of its own.

This guide provides a practical sequence for small US law firms changing managed IT providers. It is a planning framework, not a guarantee that every migration can occur on the same timetable. A firm with cloud-only systems may move quickly; one with aging onsite servers, complex legal applications, or an uncooperative outgoing vendor may need a longer, phased transition.

Switching IT providers: five handover checkpoints

The stages below are a suggested order of work, not universal deadlines. A responsible transition can pause at any checkpoint when a critical access or recovery dependency is unresolved.

Checkpoint 1 — Name the decision owner before notice is given

Appoint one firm representative who can approve access changes, authorize outages, communicate with practice-management vendors, and resolve disputes about scope. This person need not be technical; they must be reachable and authorized to make decisions.

Review the outgoing provider’s agreement for notice requirements, termination dates, handover assistance, license ownership, equipment leases, and any charges that may continue after the transition. Inform the new provider of known restrictions, rather than assuming every account or tool can be transferred automatically.

Do not start by cutting off the old provider. That may leave the new provider unable to gather documentation, verify backups, or understand a critical system.

Checkpoint 2 — Inventory the systems the firm must keep operating

Build a current list of Microsoft 365 and other cloud tenants, internet and DNS accounts, domains, email security gateways, endpoints, firewalls, switches, Wi-Fi, servers, backup platforms, telephony, practice-management software, document management, and legal-specific integrations.

For each one, note who owns it, who administers it, who pays for it, where support requests go, and what would happen if it stopped working. Identify the least replaceable assets first: domain registration, tenant administration, backup access, and systems containing client or matter information.

Request configuration documents and support records from the outgoing provider where contractually available. Sensitive credentials should move through an approved secure channel or password vault, not an ordinary email attachment or unprotected spreadsheet. Access should be limited to named people who need it.

Checkpoint 3 — Verify incoming access before removing outgoing access

The firm should retain or establish verified control of its primary accounts. Test sign-in to the identity platform, Microsoft 365 administration, domain registrar, DNS provider, backup console, and other critical portals using authorized identities. Validate recovery methods, not only normal logins.

For Microsoft 365, separate three issues: the firm’s ownership and access to its tenant, the outgoing provider’s delegated administrative permissions, and its reseller or subscription relationship. Microsoft documents that partner admin roles can be removed in the Microsoft 365 admin center, but that removal does not necessarily end the commercial reseller relationship. Check both paths explicitly.

If Microsoft Entra roles, partner relationships, or emergency access accounts are involved, ensure that a verified authorized administrator remains available while the outgoing provider’s access is retired. Never terminate a working privileged path simply because the new provider says it expects access to be ready.

The incoming provider should document what has been tested, which privileged roles are needed, and which temporary access methods will be removed after the cutover.

Checkpoint 4 — Make the switch a controlled change, not a surprise

Agree on a cutover date and communication plan. Tell staff how to reach support, what changes to expect, and whom to call if email or the internet is unavailable. Schedule potentially disruptive work outside important filing periods where practical.

The new provider should confirm that remote management and security agents are appropriate for covered devices, identify any conflicts with outgoing tools, and coordinate removal in the agreed sequence. Endpoint protection must not be unintentionally disabled during a tool replacement. Firewall changes, VPN configuration, email filtering, and backup jobs require special care because mistakes may affect many users at once.

Document an explicit fallback plan: if the new support channel fails, who can be contacted, what services can be rolled back safely, and what changes must stop pending investigation? A fallback does not guarantee that every change is reversible, but it makes escalation less chaotic.

Checkpoint 5 — Prove the new operating model works

During the first week, test ordinary user requests, a new-user or access change, the emergency communication path, critical application logins, and backup reporting. Conduct an appropriate restore test under an agreed scope—do not assume that a dashboard showing successful jobs proves recoverability.

During the first month, review the completed inventory, remaining former-provider access, recurring incidents, device coverage, priority security issues, backup exceptions, and outstanding migration tasks. Confirm that leadership understands the new support hours and decision points.

Only after the necessary handover and validation should obsolete privileged accounts, delegated roles, remote tools, shared secrets, and unused integrations be retired. The order of these actions is important; removal too early creates lockout risk, while indefinite overlap creates access risk.

What usually causes preventable downtime?

The transition often fails at an ownership boundary rather than during a sophisticated technical change.

Domain and DNS control. The registrar account may belong to someone who left the firm years ago. The outgoing vendor may have used a personal email account. Confirm access and recovery details before scheduling email or website changes.

Microsoft 365 licensing. Administration rights and reseller billing can be separate. Removing partner privileges without checking subscription relationships may leave an unexpected commercial dependency. Microsoft provides specific partner relationship management guidance for this distinction.

Backups. A backup configuration that points to the outgoing provider’s storage or credentials may not survive an abrupt termination. Verify where the protected data lives, who controls the encryption keys and repository, what happens to retained copies, and how a restoration will be performed under the new arrangement.

Legal applications. A practice-management vendor may restrict support or integrations to approved administrators. Agree which organization will coordinate escalation and test the legal team’s critical workflows after configuration changes.

Device tools. Two remote monitoring or endpoint protection products can interfere with each other. Removing the old product before the new one is operating can leave an unmonitored period. Assign a device-by-device sequence instead of attempting a blind, same-day replacement of every tool.

The handover packet the firm should keep

A complete transition ends with the law firm holding a usable operational record, not merely a ticket saying “migration complete.” Request:

• A current inventory of covered users, endpoints, networks, servers, cloud services, and critical vendors.
• A list of primary and emergency administrators, named role ownership, and how privileged access is approved.
• Domain, DNS, licensing, and subscription ownership information.
• Backup locations, protection scope, restoration responsibilities, and known exceptions.
• Network and system diagrams where relevant, plus known configuration dependencies.
• Support contact details, incident escalation rules, and after-hours arrangements actually agreed in the contract.
• A list of unresolved issues, accepted risks, pending projects, and the person responsible for each.
• Confirmation of what outgoing access and software have been removed, with any exceptions documented.

The point is not to collect passwords in a folder. Preserve controlled access, keep secrets in an appropriate vault, and make the knowledge available to authorized people if the next provider also needs to change.

Protect confidentiality during the change

A provider transition may temporarily increase the number of administrators and vendors who can access firm systems. Limit access to approved purposes, minimize the overlap period, record critical changes, and use secure transfer methods for records that could expose client matters or credentials.

The ABA’s Model Rule 1.6 addresses reasonable efforts to safeguard confidential information. Applicable professional-conduct rules and legal duties vary by jurisdiction and matter. The firm’s leadership and legal advisors should decide which additional contractual or client requirements apply to the handover.

The NIST guidance on third-party relationships also emphasizes supplier risk and the importance of communicating requirements. The commercial and technical exit process should be planned, not improvised after access is withdrawn.

Before you consider the change complete

A successful handover does not mean that every legacy issue has been fixed. It means the new responsibilities are real and usable: the firm can reach support, approved administrators can access critical services, no essential system depends on an unknown account, and the remaining risks are recorded with an owner and an agreed next action.

If you are considering a remote-first IT support partner, determine in advance who will handle any physical work and whether existing local vendors can remain involved. Changing providers should improve clarity, not create uncertainty about who comes to the office when a device fails.

Sources and further reading

• Microsoft Learn — Manage Microsoft 365 partner relationships
• Microsoft Learn — Customer removal of delegated administration
• Federal Trade Commission — Cybersecurity for Small Business
• NIST — Cybersecurity Supply Chain Risk Management Quick-Start Guide
• American Bar Association — Model Rule 1.6