What auditors want to see after a server migration

The migration went well. The new servers are up, the application team signed off, and the old hosts are switched off. Then the audit fieldwork starts, the auditor picks your migration out of the change log as a sample, and asks for the evidence. “It's been running fine for six weeks” is not evidence. It tells them the system works now. It does not tell them the change was controlled.

This is a practical list of what an auditor will ask for after a server migration, why they ask for it, and how to produce each piece as you go, so you don't have to rebuild it from chat logs afterwards.

What the auditor is actually testing

A migration is a change to production, so it falls under change management. Most frameworks have a version of this control:

• SOC 2: CC8.1 asks that changes to infrastructure and software are authorized, designed, documented, tested, approved and implemented.
• ISO/IEC 27001:2022: Annex A control 8.32 covers change management for information processing facilities.
• PCI DSS v4.0: requirement 6.5.1 lists what a change record must hold (reason, security impact, approval, testing, back-out), and 6.5.2 asks you to confirm, after a significant change, that the relevant PCI controls are still in place on the changed systems.

The auditor is not judging whether your migration was a good idea. They are checking that a defined process existed and that this change followed it. That changes what you need to show: a record made at the time, not an engineer's recollection.

The evidence, piece by piece

1. A record of the source before you changed it. The auditor needs a baseline to compare against. For a server that means the OS release and kernel, the installed packages with versions, enabled services, listening ports, local users and groups, sudo rules, cron jobs, mounts, kernel parameters, firewall rules and certificates. Capture it read-only, before anyone starts editing, and date it. A CMDB entry rarely counts here: it was written by hand and was out of date long before the migration started.

2. A plan that says what the new server must carry. Here you write down what moves, what is deliberately dropped, and what is replaced. For example, a package renamed on the new distribution, a service swapped for its successor, an old agent retired. Each deliberate difference needs a one-line reason. When the auditor later finds a difference between source and target, you want to point at this line rather than explain it on the spot.

3. Approval by someone who did not do the work. Segregation of duties is the control auditors test most often and the one teams most often fail. The approver should be named, the approval dated before the change window, and the approver should not be the engineer who ran the cutover. An approval added to the ticket after the work was done is a finding, even when everybody agreed at the time.

4. How the new server was built. If the target was built from code (an Ansible role, a Terraform module, an image pipeline), the evidence is the commit and the run log. If it was built by hand, the evidence is a runbook with every step and who ran it. Built from code is much easier to defend, because the auditor can see exactly what was applied and you can rebuild it the same way.

5. A before-and-after comparison, with every difference explained. This is the piece most migrations lack. Take the baseline from step 1, read the same facts off the new server, and compare them. Every difference should be either listed in the plan as deliberate or raised and resolved. An unexplained difference is exactly what an auditor is looking for: it means the change did something nobody intended. The comparison should be repeatable, so that someone other than the implementer can run it again and get the same answer.

6. Proof the data arrived intact. For files, that means checksums taken on both sides. For databases, row counts per table and a checksum or a logical comparison, taken after the final sync and before writes resumed. Record who ran it, when, and against which copy. A screenshot of a row count without a timestamp tells the auditor very little.

7. Security controls confirmed on the new server. This is the PCI 6.5.2 idea, and auditors under other frameworks ask for it too. The log forwarding works and the SIEM shows events from the new hostname. The endpoint agent is installed and reporting. The hardening baseline is applied and scanned. Access is limited to the same groups as before, MFA still applies, the server is in the vulnerability scanner's scope, and backups are configured, with one restore actually tested. A migration is the most common way a server quietly falls out of monitoring.

8. A record that the old server is gone. When the source was retired, what happened to its disks (sanitization per your media policy, for example NIST SP 800-88), that it was removed from the asset inventory, that its service accounts and keys were revoked, and that its DNS and firewall entries were cleaned up. An old server still running three months later, with last year's credentials, turns up in audits more often than you would expect.

The findings that come up again and again

• Approval after the fact. The ticket was approved the morning after the cutover.
• “Tested” with no artifact. The ticket says testing passed. Nothing shows what was tested or what the result was.
• The implementer checked their own work. The only comparison was done by the engineer who made the change, by eye.
• Differences without a reason. The new server lacks a package or a cron job the old one had, and nobody can say whether that was intended.
• Evidence nobody can reproduce. Screenshots with no dates, exports with no hashes, and files on someone's laptop.
• A rollback plan that was never real. The back-out section says “restore from backup”, but nobody tested it, or the source was deleted before the target was verified.

Make the evidence a by-product, not a project

Most of this costs very little if you produce it during the migration and a lot if you reconstruct it after. Three habits do most of the work:

• Attach everything to the change ticket. Baseline, plan, approval, build run, comparison, data checks and security checks all go in one place, and the auditor gets one link.
• Prefer machine-made records to screenshots. A file with a digest can be recomputed by the auditor. A screenshot cannot.
• Keep the source until the comparison passes. The old server, powered off but intact, is your rollback and the other half of your evidence. Decommission it after verification, not before.

Keep the bundle for as long as your retention policy says, and at least until the next audit period has closed. The same baseline is useful after cutover too: run the comparison again later and you can show the server has not drifted from what was approved.

Where vrtmv fits, and where it doesn't

vrtmv helps with steps 1, 2, 4 and 5 for Linux servers. It reads the source read-only (a cold disk image or a live host) and records the OS release, packages, services, and the configuration and accounts it carries. It writes a plan of what the rebuilt server must carry, with the provenance of the rule behind each mapping, and generates the Ansible role or Terraform to build it. After the rebuild, vrtmv verify checks the new server against that plan, using only what it can observe there: the package database and the carried configuration paths. A missing package is reported missing, every caveat and gap is listed, and verify exits non-zero on any parity gap, so a pipeline can stop the cutover on it. Each parity report carries a SHA-256 digest of its facts, so an auditor can recompute it.

It never uploads your data, and copying it is a step you start: vrtmv data plan writes the copy runbook, with a sha256 manifest of the source's files, and vrtmv run --copy copies the paths you name. It does not approve your change, test your application or check your security agents. Those stay in your process, with your people's names on them. Supported distributions and major versions are listed on the supported page, and your exact source and target are confirmed in scoping.

A checklist to copy into your next change ticket

• Source baseline captured read-only, dated, attached.
• Plan lists what moves, what is dropped and what is replaced, each with a reason.
• Approval by a named person other than the implementer, dated before the window.
• Build commit and run log attached.
• Before-and-after comparison attached, every difference explained.
• Data checksums or row counts from both sides, with time and operator.
• Logging, endpoint agent, hardening, access, scanning and backups confirmed on the target, with one restore tested.
• Source kept until verification passed, then retired, sanitized and removed from inventory.