.webp)
By the time a nonprofit calls me, the decision is usually already made. They are not asking whether to change providers. They are asking how to do it without the wheels coming off.
That is the right question, and almost nobody plans for it properly.
I have spent seventeen years responsible for IT support in one form or another — as an analyst, an engineer, and an architect, inside federal agencies, inside corporations, and as the outside partner. I have been on both ends of a handoff. The pattern is consistent enough that I will state it plainly: the transition is where the relationship is won or lost, and most organizations treat it as paperwork.
It is not paperwork. It is one of the highest-risk windows you will go through with a technology partner, and it deserves at least as much scrutiny as the proposal that preceded it.
Why this matters for a nonprofit right now
Every organization that changes providers takes on transition risk. For many nonprofits, that risk is landing at a time when budgets and operating assumptions are already under pressure.
Federal funding has contracted for many nonprofits, and private philanthropy has not necessarily made up the difference. When money tightens, every recurring line gets pulled into the light, and the IT contract is an easy one to question because leadership and boards may not always have a clear view of what it buys. A cheaper option can look straightforward on a spreadsheet. The transition rarely is.
At the same time, expectations around cybersecurity, privacy, and responsible data handling are increasing. Undocumented donor-platform integrations, volunteer accounts that were never removed, grant-funded software whose renewal owner is unknown, or a program site depending on connectivity nobody documented do not stop mattering because your IT is mid-transition.
A bad handoff at a commercial company is expensive. At a nonprofit, it can also interrupt the programs and services people depend on.
Where it actually goes wrong
One failure mode causes most of the others: discovery is rushed, incomplete, or never formally closed.
Everyone is eager to close and move fast. The new provider wants a start date. The outgoing provider has already mentally moved on. Discovery is the least exciting phase and the easiest to compress, so it gets compressed.
The result is predictable. Software nobody documented. Licensing renewals that sneak up. Vendors with no formal support agreement. Aging hardware with no replacement plan. Accounts belonging to people who left two years ago.
None of it shows up on day one. It shows up three months in, when something breaks and nobody has an answer — and by then the new provider is the one holding it, the relationship is already strained, and your staff have decided the change was a mistake.
I have seen organizations discover, six weeks after cut-over, that a business-critical application was running on an unsupported operating system that nobody had inventoried. That is not a technology failure. That is a discovery failure.
What a real transition should actually look like
For a straightforward environment, a well-planned takeover often runs roughly thirty to forty-five days. More complex, multi-site, or regulated environments can take longer. The work should run in overlapping phases with clear project management, engineering ownership, and technical leadership rather than being absorbed into somebody's existing workload. Any provider you are evaluating should be able to describe an equivalent process.
Week one is kick-off. A stakeholder matrix gets established, a communication plan gets written, and introductions happen. This sounds like ceremony. It is not. Most transition failures I have investigated trace back to somebody who mattered not knowing what was happening or when.
Weeks one and two are discovery. The IT assessment starts, knowledge transfer from the outgoing provider begins, the security baseline gets reviewed, and — the part almost everyone skips — somebody interviews actual users about their actual experience. Your staff know where the problems are. They have been working around them for years. Ask them.
Weeks two to three are system setup. Remote monitoring and management tenancy gets created, license delegation is established, any needed hardware is procured, and the knowledge base gets populated so support is answering from documentation rather than guesswork.
Weeks two to four are staging. Hardware is deployed, onboarding and offboarding workflows are mapped, the support team is trained on your environment specifically, and process documentation is finalized.
Weeks three to six are cut-over. Support lines go live, users are told exactly how to get help, assessment findings are reviewed with you, and — this is the deliverable to insist on — an IT roadmap is produced.
The final two weeks should include hypercare: closer monitoring against service levels and an open feedback loop, on the assumption that something will surface and it is better to catch it in week five than in month five. By the end of the transition, you should be moving into steady-state operations on a regular review cadence.
The transition should also close against a written checklist that is signed off by the project manager, provided to the client, and retained in the provider's documentation. A RACI should make clear who is responsible, accountable, consulted, and informed for major software, hardware, access, and vendor relationships.
The questions that do not get asked
I know which questions get glossed over, because I have watched them get glossed over. Ask these before you sign anything.
Who owns your documentation? If your current provider holds the only record of how your environment is configured, you are not evaluating a contract, you are negotiating a hostage release. Ask what gets handed over, in what format, and when.
Who is actually assigned to this? Not a single point of contact trying to juggle everything. You want a project manager, an engineer, and a technical lead working together, and you want their names.
Is someone coming on site? Somebody should walk the floor, meet your people, inventory hardware and software in use, and put hands on the environment. Remote discovery misses the switch in the closet that nobody documented and the laptop in the program office that has not been patched since it was issued.
What happens to accounts on day one? Credential handover, administrative access, and removal of the outgoing provider's access create a high-exposure point in the transition. There should be a written sequence, not an assumption.
What is included, and what generates an invoice? Onboarding and offboarding staff is real, recurring work. If it is billed per ticket, you will feel it every time you hire.
And the one people forget: what does the roadmap say? If onboarding ends without a clear technology roadmap and a reasonable view of next year's budget, the assessment is incomplete.
What to tell your board
Boards do not need to become technical. They do need to see that a transition is being managed rather than hoped through.
Give them three things. First, a named accountable person and a target date for completing the transition. The date may move as discovery uncovers new information, but ownership and the plan should be clear. Second, a short list of the risks discovered during assessment, organized by severity, with what is being done about each. Third, the roadmap with a budget figure attached, so next year's technology conversation starts from a document instead of a surprise.
One saying has driven my whole career: you don't know what you don't know. A transition is the one moment when you are actually allowed to find out — a new set of eyes goes through everything, and anything that has been quietly wrong for years surfaces at once. That is uncomfortable. It is also the entire value of the exercise, and it only works if discovery is done properly.
I have been through enough transitions to recognize where they fail. If the pattern in this article sounds familiar, that is because these failures are common. They do not have to be.
