What the Handover Document Doesn’t Tell You

Apr 30, 2026

Reading Time: 4 minutes

When a business changes IT providers, the incoming team receives a handover document. On a recent estate takeover, that document contained six line items: an IP address, a username, a password, and a hostname for each server. No service mappings. No documentation of how components connected to each other. No indication of what depended on what.That is where the real discovery work begins.

What a Proper IT Estate Assessment Involves

When Si Futures takes on an environment, we log into each component and review it on its own terms. Configurations are checked for correctness and alignment. Errors are identified. Each system is assessed for its function, its connections to other components, its current state, and its maintainability going forward. The question is not just “is it running?” but “is it running the way it should, and for how long will that remain true?”

On this estate, that process found things that had not been mentioned in the handover at all. All servers were running Windows Server 2012 R2, which reached end of life in 2023. One had no antivirus protection; the other was running a consumer-grade product on a business server. The mail archiving software was effectively expired. Some machines were joined to the domain and others were not, with no apparent reason for the inconsistency. Many operating system updates were outstanding across both servers.

An MX lookup on the domain also surfaced a SendMARC account managing the client’s DMARC and DKIM email authentication records — a component that is critical for protecting the business’s email domain from spoofing. It was not listed anywhere in the information the outgoing provider had shared. It was only visible because the discovery process looked beyond the list.

Why the Incoming Team Always Finds More

This is not unusual. Incoming providers almost always discover more than the outgoing documentation covers, and it is rarely because of deliberate concealment. Environments drift. Configurations are implemented as part of troubleshooting and then forgotten. Unless someone documented it at the time, that knowledge lives in the head of whoever made the change. When they move on, it goes with them.

There is also the set-and-forget problem. Anything that was configured correctly once and has been running without incident since tends to fall out of documentation over time. Not because it is unimportant, but because it has not caused a problem. Fresh eyes catch these things precisely because they are not carrying the accumulated familiarity that causes experienced teams to stop noticing what is around them.

The result is that an incoming MSP’s discovery list is almost always longer than what was handed over, and the gap is often larger than anyone expected.

The Protective Documentation Principle

Once Si Futures has mapped everything the assessment surfaces, we compile a comprehensive list and send it to the outgoing provider for confirmation. The outgoing provider is still under contract with the client during the transition period. If they confirm that the list covers everything and something is later found to be missing, the responsibility for that omission is clear. If they do not engage meaningfully with the list, that is documented too.

This is not adversarial. It is simply the right way to manage a handover when the information flow has been limited. The client is copied throughout this process and can see exactly how much work is going into filling the gaps their previous provider left. That visibility matters because it shows, without anything needing to be said explicitly, what a thorough handover actually looks like.

If something is missed despite thorough discovery, the response is the same as it always is: fix it first, keep the business running, and address the documentation afterwards. Business continuity takes priority. But having done the discovery properly means that any conversation about where a gap came from is grounded in evidence rather than assumption. This is consistent with how we approach IT strategy and planning more broadly — evidence first, then recommendation.

Discovery as Future-Proofing: IT Strategy Beyond Migration

There is a second dimension to estate assessment that goes beyond migration accuracy. The question is not just whether the environment will survive the transition, but whether it is actually fit for where the business is going.

Does the Active Directory architecture suit a team that is increasingly distributed? Would the connectivity design support international access requirements that are already emerging? Is there a reason why users need on-premises infrastructure, or has that assumption just never been examined? These questions come up when someone takes the time to understand an environment in the context of the business, not just as a technical configuration to be replicated.

Just because something is working does not mean it is fit for purpose. The handover is an opportunity to close that gap as well, and to build an environment that can grow with the company rather than constrain it.

The most valuable thing a fresh set of eyes brings to an IT estate is not technical expertise alone — it is the absence of assumptions. Every undocumented component that gets surfaced during discovery is a risk that would otherwise have been inherited silently.

What Thorough IT Provider Discovery Looks Like in Practice

We are building network diagrams for this estate from scratch, because none were provided. We are sharing those diagrams with the outgoing provider to demonstrate that we are doing the work and to ensure full transparency about what we have found. The list of what needs to be migrated will be larger than the six line items we were given at the start.

That is not a problem. It is what thorough discovery looks like.

Si Futures provides managed IT services across South Africa and the United Kingdom. If you are planning an IT provider transition and want to understand what a proper discovery process involves, speak to our team.
author avatar
Rudie De Vries

Let’s connect