How to Switch IT Providers in Los Angeles Without Downtime

You can switch IT providers without downtime if the handover is treated as a project with a list, an owner, and a date. The work splits cleanly into three months: 30 days to take custody of credentials, documentation, and licensing; 60 days to cut over monitoring, security, and backups and prove they run; 90 days to close out vendor relationships, finish the documentation, and hold a review. Everything below is the list.

Almost every bad transition we are called into fails in the same place: the outgoing provider holds something the client never asked for, and nobody notices until it is needed. Domain registrar access, backup encryption key, license tenancy, and alarm panel password. Ask for it all while you still have a contract.

Before you give notice: five things to do first

1. Read your agreement for the term, the notice period, and the offboarding clause. Thirty days written notice is common. Auto-renewal on an anniversary date is also common, and missing it by a week can cost you a year.
2. Inventory what you know you have. Users, mailboxes, servers, firewalls, switches, wireless controllers, line-of-business applications, and the vendors behind each. You will not get it complete; you are establishing a baseline so you can tell what the outgoing provider adds to it.
3. Find out who owns your domain name. Log in to the registrar yourself. If you cannot, that is the single most urgent item on the list, because email and the website both depend on it.
4. Pick the incoming provider and set a target cutover date before you give notice, so you never have a gap with no one covering the help desk.
5. Tell your staff a date and a reason. A transition with no internal communication generates tickets that look like outages.

What to demand from the outgoing provider

This is the handover list. Ask for all of it in one written request, with a deadline, and copy whoever signed the contract on both sides. Anything the provider cannot produce is a finding for the new provider’s first-week risk list.

Credentials and administrative access

• Global administrator access to Microsoft 365 or Google Workspace, held in an account your business owns.
• Local administrator and domain administrator credentials for every server and for Active Directory or Entra ID.
• Firewall, switch, wireless controller, and any out-of-band management credentials.
• Hypervisor and storage console credentials.
• Backup console credentials and the encryption key or passphrase. A backup you cannot decrypt is not a backup.
• Line-of-business application administrator accounts, including any vendor support portal logins registered to the provider rather than to you.
• A full export of the password vault entries that relate to your environment.
• Confirmation of which accounts belonged to the provider’s staff, so they can be disabled on the last day rather than discovered a year later.

Documentation

• Network diagram, including public IP assignments, VLANs, and any site-to-site tunnels.
• Asset inventory with make, model, serial, warranty end date, and location for every server, firewall, switch, access point, and workstation.
• Application inventory: what each system does, who the vendor is, who the internal owner is, and what it depends on.
• Standard operating procedures that the provider wrote for your environment, especially onboarding, offboarding, and anything with a manual step.
• Change history for at least the last twelve months.
• Open ticket list at the moment of handover, with owner and status.

Licensing and subscriptions

• A list of every subscription with a renewal date, seat count, and who is billed.
• Confirmation of which licenses sit in your own tenant and which sit under the provider’s agreement. Licenses bought through a provider’s cloud solution provider relationship usually have to be transferred, and that transfer takes lead time.
• Antivirus, EDR, backup, and email security subscriptions: the same question, since these are the ones most often held in the provider’s name.
• Any hardware still under a lease or a hardware-as-a-service agreement, with the term and the buyout figure.

Domain, DNS, and certificates

• Registrar account access for every domain you own, including the ones you forgot you own.
• Authoritative DNS control, whether that is at the registrar, a hosting provider, or a content delivery network.
• Current zone export, so the new provider can rebuild the records if a migration goes wrong.
• SPF, DKIM, and DMARC record inventory, since these break email in ways that look like an outage but are not.
• TLS certificates: where they are issued, when they expire, and who renews them.

Backups and recoverability

• What is backed up, on what schedule, to where, and with what retention.
• The last successful restore test, with evidence. If there is not one, say so in the handover record.
• Copies of any backup data held in the provider’s own cloud, and a written commitment to a deletion date after you have your copy.
• Immutability and offsite status for each backup set, since ransomware recovery depends on both.

Contracts and commercials

• The signed agreement and every amendment.
• Final invoice reconciliation, including any prepaid blocks of hours.
• Written confirmation of the last day of service and the deprovisioning date for the provider’s own accounts and tools.

The 30-60-90 day handover plan

Days 1 to 30: take custody and stop the bleeding

The goal of month one is that nothing important is held only by someone who is leaving.

• Issue the handover request above with a deadline inside the notice period.
• Create your own global administrator account, verify you can use it, and store the credentials somewhere the business controls.
• Take registrar and DNS control first, ahead of everything else.
• Have the incoming provider run a discovery pass and compare their findings against the outgoing documentation. The gap between the two is the real handover risk.
• Verify backups by restoring something, not by reading a report.
• Agree who answers the service desk on each day of the transition, in writing, so no ticket falls between two providers.

Days 31 to 60: cut over and prove it

• Deploy the new monitoring and remote management agents, then confirm device counts match the asset inventory.
• Deploy the new endpoint detection and response tooling, and only then remove the outgoing provider’s agents. Overlap is safer than a gap.
• Move backups to the new platform, run a restore test, and record the result.
• Rotate every administrative credential the outgoing provider held, including service accounts.
• Disable the provider’s named accounts in your tenant and on your network gear.
• Transfer licensing tenancy, which usually has the longest lead time of anything on this list.
• Re-point vendor support relationships so the new provider can open cases on your behalf.

Days 61 to 90: close out and review

• Confirm the outgoing provider’s remaining access is gone, using an access review rather than their word.
• Confirm their copies of your backup data have been deleted on the agreed date.
• Finish the documentation the new provider is building, and take an export of it.
• Review the open ticket list from handover day and close what is left.
• Hold a 90-day review: what broke, what was missing, what the new baseline is.

The handover checklist

One line per item, initialed when received and verified. Received and verified are different columns for a reason: a credential that has not been tested is a claim.

What goes wrong, and how to keep it from going wrong

• The domain is registered to the provider. Fix this first, in week one. A registrar transfer can take days and requires the current holder’s cooperation.
• Licenses live under the provider’s agreement. Seats can lapse mid-transition. Ask which subscriptions are in your tenant versus theirs on day one, not day sixty.
• The backup encryption key was never handed over. The console transfers, but the data does not decrypt. Explicitly ask for the key and test a restore with it.
• Both providers’ agents run at once and fight. Two endpoint security products on the same machine cause the outages that people blame on the switch. Sequence the removal; do not skip it, and do not do it early.
• Nobody owns the service desk for a week. Write down which provider answers on which date, and tell the staff.
• Credentials are rotated, but service accounts are missed. Scheduled tasks, backup jobs, scanner-to-email accounts, and line-of-business integrations fail quietly a few days later.
• The relationship ends badly, and cooperation stops. Make the handover request early and in writing, while the contract still obliges them. Professional disagreements are normal; get the list before you have one.

What a clean switch looks like on a calendar

For a 25 to 100-person business with one office, a server or two, and Microsoft 365, a well-run switch takes about 90 days end-to-end: one to two weeks to evaluate and select, notice served, then the three phases above. Compressing it to 30 days is possible when the environment is entirely cloud-based, and the outgoing provider cooperates. It is not possible when the domain, licenses, or backups have to be moved, because those have external lead times you do not control.

If you have not yet chosen an incoming provider, our evaluation scorecard for LA IT companies covers the criteria and questions to ask. If you are still deciding whether to move at all, the honest test is whether the problems you have are about capability or about attention; a provider who cannot do the work will not improve, and a provider who is not paying attention sometimes will.

➤ Get Your Free IT Assessment

Frequently Asked Questions About Switching IT Providers