Post-Migration: Cleanup, Hardening, and Decommission Proof

"So we're done?" The project manager asks it at 09:15 the morning after cutover, kindly, with the closure form already open. Partners are connecting, files are landing, and everyone wants to say yes. The honest answer is a list. The new server was built under project pressure and still carries the shortcuts that made the night possible. Those include a broad-rights migration account, a firewall rule that says "any", a password policy relaxed for temporary passwords. The old server is frozen but alive, with a few late files on it and a log of who is still knocking. And the audit trail now has a seam that an auditor will find in a year unless it is documented today.

Post-migration is the work between a successful cutover and a finished migration. This closing article of our Platform Migration Mechanics series covers that work. It covers the late-arrival sweep, the shortcut-removal list, the hardening baseline, and log continuity across the switch. It also covers proving the old server is quiet and the decommission checklist that finally lets it power off. Everything here applies whatever platform you moved to.

The governance of this phase (the soak period, the evidence packs, who signs the decommission decision) is in migration validation and rollback. This article is the list governance signs off on.

The Morning After: The Late-Arrival Sweep

The write freeze on cutover night made the old inboxes stable for the final delta. It did not make them permanently empty. Three kinds of partner still reach the old server afterward. These are cached resolvers, long-running jobs that cached the lookup for the life of the process, and IP-address connectors who missed the notice. If the freeze was read-only accounts, their uploads failed and they retried elsewhere. If it leaked for any account (a shared administrative account, a folder outside the frozen set), files may have landed. The sweep finds both.

# 1. Anything written on the OLD server since the final delta stamp (02:15 on cutover night)?
find /srv/sftp -type f -newer /root/migration/final-delta.stamp -printf '%TY-%Tm-%Td %TH:%TM  %s  %p\n'
#   Windows equivalent: forfiles /P D:\transfers /S /D +[cutover date] /C "cmd /c echo @fdate @ftime @fsize @path"
#   expected: empty. Anything listed is a late arrival -> copy to the new server (temp names excluded),
#   verify by hash, then tell the partner it was received.

# 2. Who is still knocking? Connection attempts in the old server's log since the switch, counted
#    by source address (rotate the log at cutover, or filter by date; adjust the field to your format)
grep -E "connection from|login" /var/log/sftp-old/activity.log | awk '{print $NF}' | sort | uniq -c | sort -rn
#   each source address is a straggler: match it to a partner in the register and make the call

# 3. Repeat daily through the soak; the list should shrink to zero and stay there

Late arrivals are moved to the new server with the same care as the final delta (temp names excluded, hashes compared). Each is reported to its partner, who believes the file was delivered. The straggler list matters more. Every address on it is a partner whose automation has not followed the migration. The register from the migration inventory says who they are and how to reach them. The old server's log keeps producing this list as long as it runs, which is one of the two reasons it stays on.

The Shortcut-Removal List

Every migration takes shortcuts, and the honest ones are written down as they are taken so they can be reversed. If nobody wrote them down, the list below is what the night usually required. Each is a finding until removed, with an owner and a date.

MIGRATION-ERA SHORTCUTS -- remove within the first week, before the soak is declared

[ ] Migration copy account (broad read/write across every partner folder)    disable, then delete
[ ] Temporary administrator accounts created for the night                     delete; one named admin remains
[ ] Firewall rule allowing "any" source to the new server for the seed copy    remove; partner IP rules only
[ ] Firewall rule from old server to new for the delta copies                  remove after the last sweep
[ ] Staging folder used for the seed (outside any partner jail)                delete contents, then folder
[ ] Relaxed password policy set so temporary passwords could be short/simple   restore full policy
[ ] Temporary passwords still in force where the partner could have changed    force change or confirm strength
[ ] Host-key checking disabled in your own scripts during rehearsal            re-enable; pin the new fingerprint
[ ] Certificate verification disabled in any smoke-test or job configuration   re-enable; never leave off
[ ] Verbose or debug logging turned on for the night                           return to normal level
[ ] Test partner accounts (smoketest, probe accounts)                          delete, with their folders
[ ] Copies of private keys and PFX bundles on workstations, temp, downloads    destroy; confirm by search
[ ] Exported configuration of the old server containing password hashes       encrypt into the archive; delete the loose copy
[ ] DNS TTL left at five minutes                                               raise only AFTER decommission
[ ] IP allow list set to "accept all" so nothing would be blocked on the night set the real list

Two lines deserve emphasis. The private-key copies are secrets that outlived their purpose. A host key carried by hand lives in a download folder on someone's laptop until it is deliberately destroyed. And "I think I deleted it" is not an entry in the evidence pack. Search the machines that touched it. I have found one in a recycle bin. And the TTL is the one shortcut that should not be reversed yet. A five-minute TTL is what keeps rollback a five-minute operation through the soak. Raise it on decommission day. Migration-era credentials get the hygiene in service account hygiene: created for a purpose, removed when the purpose ends. Temporary accounts have a strong survival instinct. The ones you do not delete this week are the ones finding stale and orphaned accounts turns up in two years, still called "migtemp2".

Applying the Hardening Baseline

The new server was built to pass the smoke tests, not a security review. Now it gets the same baseline every other transfer server in the estate is held to. That is the program in hardening program overview, applied item by item and verified from the outside. The items most often left loose after a migration, with the check for each:

Platform features do most of the work once switched on. Per-account and global IP allow and block lists, lockout thresholds, and per-account protocol restrictions are ordinary settings on a server such as Sysax Multi Server. Their equivalents exist across platforms. The point of the baseline is not any one setting but the verification pass that follows. Hardening verification describes testing the server as an outsider would. That testing's output is the first security evidence the new platform produces. If plain FTP was retired as part of this migration, the same pass is where proving FTP is gone gets its evidence.

Log Continuity Across the Switch

An auditor asking "who downloaded the Bayside manifest in March?" does not care that the server changed. The answer must be findable whether the event happened before or after cutover. That means the old history is preserved intact and the new history begins with no gap. Four pieces of work make the seam invisible.

1. Archive the old server's logs as a sealed set. Copy every log file to the archive location: activity, authentication, transfer records, and the database export if the platform logs to one. Record a hash of each file beside it, so later questions about tampering have an answer. The reasoning is in tamper resistance. Keep the old server's own copy in place until decommission.
2. Confirm the new server logged from its first minute, at the level the old one did. Confirm that the stream reaches the same central collector. A platform that logs to both a file and a database — Sysax Multi Server does both — gives the collector two sources to draw from. Whichever the estate uses, the collector's record of "first event from sftp-new" should be within seconds of the service start. The collector side is in centralizing logs.
3. Write the continuity note. A short record, stored with both archives and in the register, that says where every period's records live. Without it, the archive is a directory nobody can interpret in two years.
4. Re-point everything that reads the logs. Alert rules, freshness checks, and reports were parsing the old server's format and hostname. Each is updated and tested with a deliberate event — a failed login, a late file — as alerts from transfer logs recommends. An alert that watched the old server will now be silent forever, which looks exactly like a healthy estate.

Northgate Retail's freshness alert was one of those. It watched the old server's log for a supplier feed that arrived every weekday. After cutover the alert went quiet, because the log it read was frozen and the feed was landing elsewhere. Green for five months. When the feed itself stopped in the fourth month, the alert, still watching an empty log, said nothing about that either. Accounts payable noticed, eventually, which is how these things are usually noticed. The rule now is that every re-pointed alert is tested by making it fire.

LOG CONTINUITY NOTE -- transfer.example.com

Records up to Mar 14 02:35    sftp-old.example.com   archive: \\archive\transfer-logs\sftp-old\
                              format: old platform activity log (one line per event, local time)
                              sealed: sha256 manifest sftp-old-logs.sha256, Mar 15, by [name]
Records from Mar 14 01:30     sftp-new.example.com   live: central collector, source "sftp-new"
                              format: new platform log (UTC); database table transfer_events
Overlap Mar 14 01:30-02:35    both servers logging; old was frozen (reads only) from 02:00
Timezone                      old logs are local time; new logs are UTC -- adjust when correlating
Retention                     both sets under the transfer-log retention rule (see policy)

The timezone line is not decoration. Platforms disagree about whether to log in local time or UTC. A migration is the most common way an estate ends up with both. Note it once, here, and whoever correlates events across the seam next year will not lose an afternoon to a one-hour discrepancy. Retention rules apply to the archived logs exactly as they did on the old server. The article retention policy for transfer servers covers setting them.

Proving the Old Server Is Quiet

The old server powers off when two things are true. First, the new server has carried production through a full business cycle with the evidence to show it. Second, the old server has received no legitimate connection attempt for a period long enough to include every partner's rhythm. The first is the soak period the validation article governs. The second is a measurement from the old server itself.

• Its activity log shows every login attempt. Stragglers appear here first, by source address and account name.
• The firewall in front of it logs every connection to its ports, including the ones the frozen server refused. This catches partners whose login never got far enough to be logged by the application.
• Its listener counters — connection counts per port, read weekly — give the trend: falling to zero and staying there.

Each straggler is contacted and moved, and the clock restarts. The quiet period is measured from the last legitimate attempt, not from cutover night. Internet scanners and probes will keep touching the old address. They are recognized by their pattern (no valid account name, many addresses, no follow-up) and excluded from the count. When the quiet period covers a month-end and any quarterly cycle in the estate, the measurement is done. The "nobody arrived" evidence in proving FTP is gone applies to a retired server as it does to a retired protocol.

The Decommission Checklist

Decommission is a sequence, not a power button. Every line produces evidence, and the order matters because later steps destroy things earlier steps still need.

DECOMMISSION -- sftp-old.example.com          executed only after the soak sign-off

Evidence
[ ] Soak evidence packs complete for every flow; sign-off recorded
[ ] Quiet-period measurement: zero legitimate attempts across a full business cycle
[ ] Last late-arrival sweep run and empty

Preserve
[ ] Final archive of the old server: configuration export (encrypted -- it may hold hashes),
    account list, folder tree listing, sealed logs, certificate (public part) -- stored, hashed
[ ] Any files remaining on the old server compared against the new; nothing unique left behind
[ ] Old server disk image or snapshot retained for a few weeks in case a question arises

Identity
[ ] CARRIED host key: old server's copy destroyed (the new server is now the only holder)
[ ] REISSUED host key: old key retired; partners' notices already said so
[ ] Certificate: if the private key was carried, old copy destroyed; if replaced, old cert
    left to expire (revoke only if compromise is suspected)

Network
[ ] Firewall rules to and from the old address removed on your side
[ ] Partners told to remove the old address from their allow lists -- closing the
    "add, don't replace" instruction from the migration notice
[ ] DNS: old host records removed; TTL on the alias raised back to normal
[ ] IP released, or kept reserved so nothing else answers on it for a while

Estate
[ ] Monitoring, backup jobs, patch schedules, and log collection for the old server retired
[ ] License released or reassigned; asset and configuration registers updated
[ ] Disks wiped to the standard in secure deletion basics before the hardware is reused

Power off
[ ] Service stopped; server shut down; date and name recorded in the register

The identity lines are the ones with teeth. Consider a host key carried as described in migrating keys and certificates and still present on a decommissioned but unwiped server. It is a private key on a disk in a storage room. A carried certificate key is the same. Destroy them deliberately and record it. Leaving the old certificate to expire rather than revoking it is normal when nothing was compromised. Revocation signals that something went wrong, not that you tidied up. The wiping standard is in secure deletion basics. And the instruction to remove the old address closes a loop opened weeks ago. Partners added the new address without removing the old so rollback stayed possible. Now the old rule is an unnecessary hole in their firewall, and it is yours to tell them so.

Closing the Migration

A few things make the new platform the estate's normal rather than its recent event. The migration register becomes the flow inventory again, describing the new server. The new platform gets the documentation the old one never had. That covers where its host keys and certificates live, its passive range and external address. It also covers its IP lists, its log locations, its service account. These are the settings this series had to rediscover on the old server. Write them down while fresh, and take the backup in backing up transfer configuration. The new certificate's expiry is in the monitoring. The migration-era credentials are gone. And a date is set for a review one business cycle out. That review belongs to our choosing a file transfer server series, not to the migration.

Wrapping Up: Finished Means Nothing Left Behind

A migration is finished when the old server is off and nothing depends on it. The work between cutover and that moment is specific. Sweep the old server for late arrivals and stragglers, daily, until the list is empty. Remove every shortcut the night required. Apply the hardening baseline to the new platform and verify it from outside. Seal the old logs, confirm the new stream is continuous, and write the continuity note. Measure the old server's silence through a full business cycle. Then decommission in order (evidence, preserve, identity, network, estate, power off). In that process, destroy the carried keys on purpose and tell partners to close the old address. Then tell the project manager yes.

That completes the series. The layer map in what actually moves in a platform swap is where the next migration starts. And the cutover night runbook is the page to reread the week before it.

Frequently Asked Questions