MFT Migration Playbook: Move Partners and Flows Safely

Moving to a new managed file transfer platform is mostly a partner and identity migration, not a server build: every trading partner trusts a host key, a certificate, an address and an account that the old platform holds, and every one of those has to move, change or be retired without breaking a business process or leaving a forgotten door open. Organisations replace MFT platforms after an emergency patching crisis, at end of support, when moving from on-premises to a hosted service, or when consolidating several file transfer servers after a merger. This playbook covers the migration itself: the inventory, partner trust (SSH host keys, AS2 and FTPS certificates, IP allow lists), flow and automation cutover, the parallel-run period, and the decommissioning of the old platform and its data. It is vendor-neutral and does not name products. Hardening the platform you move to is covered in the Managed File Transfer (MFT) Security Guide, and choosing it in the Secure File Transfer Buyers Guide.

Key takeaways

Inventory flows, not servers. The unit of migration is the partner flow: who sends what, over which protocol, with which credential, on what schedule, to which downstream system.
Decide host key and certificate strategy first. Carrying keys over avoids partner change but carries any past exposure with them; new keys are cleaner but need every partner to update trust on a dated plan.
Do not migrate dormant accounts. Each partner account, SSH key and API credential should be re-justified by an owner before it is recreated on the target.
Run in parallel by partner wave, with a named rollback. Cut partners over in small groups, keep the old endpoint configured but closed for a short window, and reconcile file counts both sides.
Decommission is part of the project. Old servers hold files, logs, keys and partner credentials; archive what retention requires, sanitise the rest and close every firewall rule.

What an MFT migration actually moves

Object	Migration approach	Watch for
Partner accounts (SFTP, FTPS, web portal)	Recreate only accounts an owner confirms; one account per partner flow	Shared accounts used by several partners; accounts with no transfers in months
Partner SSH public keys (inbound SFTP)	Import with per-key restrictions; reconfirm each key with the partner	Keys with no owner or expiry; one key reused across environments
Server SSH host keys	Carry over or replace (see next section)	Partners pinning the old key and failing hard at cutover
Outbound credentials (your keys and passwords on partner servers)	Generate new key pairs on the target; register them with partners; remove the old ones	Private keys copied from the old server and left in two places
AS2 and FTPS certificates, AS2 identifiers	New or reissued certificates exchanged on a dated plan; AS2-From and AS2-To values kept identical	Expired partner certificates hidden by the old platform's warnings being ignored
Flows, schedules, triggers and scripts	Rebuild from the inventory; test each with real file shapes	Pre and post-processing scripts with embedded credentials
Network addresses and DNS names	Keep the same DNS names where possible; publish new source IPs to partners early	Partner firewalls allow-listing your old egress IPs
Integrations (ERP, storage, message queues, APIs)	Recreate with new service identities scoped to each target	One high-privilege integration account reused for everything
Files at rest, archives and audit logs	Move only what retention requires; archive logs for their retention period	Years of files nobody needs, left on the old server after cutover

The data at rest matters more than it looks. Mass exploitation of internet-facing MFT servers has repeatedly turned stored files into extortion material: CISA's 2023 advisory on the Cl0p ransomware gang exploiting CVE-2023-34362 describes a campaign against a file transfer web application and recommends inventories of authorised accounts, segmentation and encrypted, immutable backups. A migration is the cheapest moment to stop carrying old files. See the Cl0p Threat Actor Profile.

Partner trust: host keys, certificates and addresses

Partners do not trust your platform, they trust a set of identifiers. RFC 4253 makes the SSH client responsible for checking that the server host key really belongs to that server, and warns that accepting an unverified key leaves the protocol "insecure against active attacks". A well-run partner will refuse to connect when your host key changes, which is exactly what you want from them, and why the change must be planned.

Option	How it works	Choose it when	Trade-off
Carry the SSH host key over	Install the old private host key on the target under change control	Many partners, little ability to coordinate, and no reason to suspect the old server	Any past exposure of the old key moves with it; the key now exists in two places until the old server is sanitised
New host key, announced in advance	Publish the new key fingerprint through an authenticated channel weeks ahead; partners add it before cutover	The old server was ever suspected of compromise, or the key algorithm is weak	Partners who miss the notice fail at cutover; needs a contact list that works
Both keys during overlap	The target presents new and old keys of different algorithms; clients that support host key rotation learn the new one	Partners mostly use modern SSH clients	Client support varies; still needs a dated removal of the old key
New AS2 or FTPS certificate	Exchange the new certificate, agree a switch date, accept both during overlap where the product allows	Always for certificates near expiry or using old algorithms	Partner change windows are slow; start early

Host key rotation support: the SSH client option UpdateHostKeys (ssh_config) can accept additional host keys a server sends after authentication, but only when the host was already trusted by a plain key in the user's known hosts file, and it needs the server to support the extension. Treat it as a help for some partners, not a plan for all.
Never ask partners to relax checking: StrictHostKeyChecking no allows connections to hosts whose key has changed. Asking a partner to set it to get through cutover teaches them to accept a man-in-the-middle.
AS2 identifiers stay fixed: RFC 4130 requires AS2-From and AS2-To in every AS2 message, case-sensitive, and requires a response to swap them exactly. Keep the identifiers the partner already has configured; change only the URL and certificate.
AS2 certificates are often self-signed: RFC 4130 allows self-signed X.509 certificates exchanged when the trading relationship is set up. Exchange new ones through a channel you can verify, such as a call to a known contact to confirm the fingerprint.
Addresses: partners often allow-list your egress IP addresses. Publish new source addresses with the first notice, not the last.

Where identity fits

An MFT platform is a dense store of non-human identities: partner accounts, inbound SSH keys, your own outbound private keys, AS2 signing and encryption keys, and service accounts into ERP and storage systems. The migration is the one moment every one of them must be touched, so use it to clean up. The CISA advisory above notes that rebuilding a file transfer web server while keeping its database left the attacker-created accounts in place: a migration that copies the account database wholesale can do the same.

Re-justify, then recreate: export accounts and keys from the source, send each owner a list, and recreate only what they confirm. Unconfirmed accounts are not migrated.
New outbound keys: generate new private keys on the target rather than copying them from the old server. NIST IR 7966 on SSH access management centres on managing SSH user keys used for automated access, which is exactly what outbound MFT keys are.
Secrets out of scripts: move passwords and keys referenced by scripts into the platform's credential store or a secrets manager. See the Secrets Management Guide.
Admin access: administrators of the new platform sign in through the identity provider with phishing-resistant MFA; no local admin account in daily use.

Integration accounts are covered in depth in the Managed file transfer (MFT) integration security guide.

The phased playbook

Inventory (weeks 1 to 3): export every partner, flow, schedule, script, key, certificate, listener and firewall rule from each source server. Join it to transfer logs to find which flows actually ran in the last 90 days (a lookback we recommend; use your own business cycle if quarter-end or year-end flows exist). Record the data class of each flow.
Decide and design (weeks 2 to 4): choose the host key and certificate options above, set retention per flow on the target, decide which protocols each partner will use (this is the time to move partners off plain FTP), and design the target network position so administration interfaces are not internet-facing.
Build and harden the target: follow the hardening steps in the MFT security guide, connect logs to the SIEM before the first partner moves, and test restore of the platform configuration.
Notify partners: send a dated notice with new host key fingerprints, certificates, addresses and the switch date, through a channel partners already trust. Ask each partner to confirm a test date. Partners who do not respond go in the last wave.
Pilot wave: move internal flows and two or three cooperative partners. Run both platforms, reconcile file counts and checksums for every transfer, and confirm downstream systems processed each file once.
Partner waves: move partners in groups sized so the team can support every failure on the same day. Avoid business peaks such as payroll and month-end runs. For each partner, close the account on the old platform once the first successful production transfer completes on the new one.
Rollback: keep each moved partner's old account configured but disabled for a short window (two weeks is our recommendation). Rolling back means re-enabling one account and reverting DNS or the partner's address, so record exactly what was changed per partner.
Decommission: archive logs and any files retention requires, revoke the old outbound keys from partner servers, revoke certificates, delete firewall rules and DNS records, and sanitise the old storage under your media sanitisation process. NIST SP 800-88 Rev. 2 (September 2025) gives the sanitisation guidelines.

Duplicates and missed files

The parallel period creates two risks: the same file processed twice, and a file sent to the platform that is no longer polled. RFC 4130 recommends that AS2 receivers detect replayed messages by Message-ID or business transaction identifier and discard duplicates; apply the same idea to SFTP flows by recording file names, sizes and checksums and checking downstream for duplicates. Poll the old inbound folders daily during the window and alert on any file that arrives.

Choosing the approach

Big bang or waves: waves are the default. A single cutover only suits a small partner count where every partner can test on the same day.
Self-hosted to hosted service: the provider takes over patching of the platform, which removes the emergency patching burden that drove many migrations, but you must confirm where files are stored, how long the provider retains logs, and how you will export them on exit.
Consolidating several servers: reconcile duplicate partner accounts first; the same partner often has different accounts and keys on each server.
Small organisations: with a handful of partners, a new host key and a single coordinated cutover day may be simpler than parallel running. Do not keep the old server running "just in case".
Large organisations: appoint a partner-communications owner, track every partner's state on a board (notified, tested, live, old account closed) and report it weekly.

Detection and measurement

Monitor both platforms throughout. On the old platform, any successful login after a partner's cutover date is either a missed partner or an intruder. On the new platform, failed host key or certificate validation from a partner usually means a missed notice, but it can also be a partner being intercepted.

Signal	Where	Why it matters
Logins to the old platform after a partner's cutover	Old platform authentication log	Missed migration or misuse of a credential that should be dead
Files arriving in old inbound folders	Old platform transfer log	A partner still sending to the old endpoint; data that nobody will process
Accounts created outside the migration change record	Both platforms' admin audit logs	The CISA advisory recommends reviewing for new or unrecognised accounts
Spikes in download volume per account	New platform transfer log, network monitoring	Bulk exfiltration over the file transfer service
Transfer failures by partner	New platform	Trust or address changes the partner did not apply

Partners migrated: share of partners live on the target with the old account closed. Target 100 percent before decommissioning.
Accounts not carried over: share of source accounts and keys retired rather than migrated. A low figure suggests the old database was copied, not reviewed.
Reconciliation gaps: transfers with mismatched counts or checksums between platforms during parallel running. Target zero unexplained.
Old platform traffic: successful sessions to the old platform per week after each wave. Should fall to zero.
Time to decommission: days from last partner cutover to old storage sanitised and firewall rules removed.

Common failure patterns

Copying the account database: moving every account and key across "to be safe" migrates dormant partners and any account an attacker added, exactly the risk CISA describes for rebuilt servers.
Telling partners to ignore host key warnings: a cutover that depends on partners disabling host key checking leaves them exposed to interception long after the project ends.
Forgetting outbound flows: pulls and pushes your platform makes to partner servers depend on your egress addresses and your private keys; they break silently if the partner allow-list is not updated.
Old server left running: an unpatched file transfer server kept online "for reference" is still internet-facing. If it must stay, take it off the internet and remove its partner accounts.
Retention reset to forever: the target is built without per-flow retention, so files accumulate again and the next breach has years of data to steal.
Scripts moved with credentials inside: pre and post-processing scripts copied verbatim keep plaintext passwords and old key paths.

Framework mapping

Migration activity	NIST SP 800-53 Rev. 5	NIST CSF 2.0	MITRE ATT&CK
Flow and data inventory	CM-8 System Component Inventory	ID.AM-03 (data flows)	n/a
Partner account and key review	AC-2 Account Management, IA-5 Authenticator Management	PR.AA-05	T1078 Valid Accounts
Host keys, certificates, protocol choice	SC-8 Transmission Confidentiality and Integrity, SC-12 Cryptographic Key Establishment and Management	PR.DS-02	T1557 Adversary-in-the-Middle
Target network position	SC-7 Boundary Protection	PR.IR-01	T1190 Exploit Public-Facing Application
Change control of cutover waves	CM-3 Configuration Change Control	n/a	n/a
Monitoring both platforms	SI-4 System Monitoring	DE.CM-01	T1048 Exfiltration Over Alternative Protocol
Log archive and decommissioning	AU-11 Audit Record Retention, MP-6 Media Sanitization, SC-28 Protection of Information at Rest	PR.DS-01	n/a

Practitioner checklist

Every partner flow inventoried with owner, protocol, credential, schedule, data class and last successful run.
Host key and certificate strategy decided and fingerprints published through an authenticated channel.
Every account and key re-justified by an owner before it is recreated; dormant ones retired.
New outbound key pairs generated on the target; old public keys removed from partner servers.
Per-flow retention set on the target before the first partner moves.
Logs from both platforms in the SIEM, with alerts on old-platform logins after cutover.
Partner waves scheduled away from business peaks, with a per-partner rollback record.
Reconciliation of file counts and checksums for every transfer during parallel running.
Old platform logs archived, storage sanitised, firewall rules and DNS records removed, certificates revoked.

Managed file transfer (MFT) migration playbook: move partners and flows without losing control