Migrating off legacy managed file transfer: a 30-day playbook

Legacy managed file transfer infrastructure is one of the more stubborn categories of technical debt in regulated industries. The servers are old; the protocols — SFTP, AS2, OFTP2 — have been running long enough that no one quite remembers all the partner integrations that depend on them. The security posture is frequently poor (unpatched versions, weak cipher configurations, shared service accounts with no MFA), but the blast radius of breaking a partner integration in healthcare or financial services is real, and that blast radius has historically made security teams reluctant to force the migration.

The calculation is changing. Aging on-prem MFT infrastructure has become a visible attack surface. The combination of known-vulnerability exposure on unpatched platforms, weak authentication on partner-facing endpoints, and the sensitive data flowing through these systems makes them attractive targets for both opportunistic actors and deliberate supply-chain attacks. Organizations that have delayed migration are now doing the work under adverse conditions — reactive rather than planned.

We’ve helped a significant number of security teams work through this migration. Here’s what a 30-day execution looks like when it goes well.

Why this comes up now

Several converging pressures are pushing organizations to finally pull the trigger on MFT modernization.

Vendor end-of-life cycles are forcing the issue for some organizations. On-prem MFT products that were installed in the mid-2010s or earlier are hitting end-of-support windows, meaning no more security patches. Running file-transfer infrastructure that receives partner connections from the public internet without security patches is an exposure that most compliance frameworks will flag in a risk assessment.

Audit scrutiny on perimeter services has increased. Assessors reviewing environments under HIPAA, CMMC 2.0, or NYDFS Part 500 are increasingly examining the security posture of partner-facing file-transfer infrastructure specifically — authentication controls, TLS configuration, audit logging completeness, and patch level. Findings in this category have become common, and remediation through patching is often difficult on legacy platforms.

The operational cost of self-hosting has become harder to justify as cloud alternatives have matured. Maintaining on-prem MFT infrastructure requires server capacity, OS maintenance, network configuration, certificate management, and application patching — a steady operational tax that security and infrastructure teams are increasingly reluctant to carry when SaaS alternatives exist that eliminate it.

Partner integration requirements are themselves pushing modernization. Many organizations find that their partners are requesting HTTPS-based file transfer or modern API integration alongside SFTP and AS2. Legacy platforms often don’t support these newer integration patterns well, leading to a sprawl of parallel infrastructure.

Week-by-week plan

Week 1: discovery and dependency mapping.

Before anything moves, you need a complete map of what’s running. This means: every SFTP account and the partner or system behind each one; every AS2 trading partner relationship (partner ID, certificate, URL endpoint on their side); every OFTP2 session if applicable; every internal system that drops files into a watched directory; every scheduled script that connects to the MFT server. This inventory almost certainly doesn’t exist in complete form — build it from connection logs, not from documentation that was written years ago.

Key artifact: a dependency map with a named owner for every integration. “Marketing uses this” is not an owner. The owner is the person who will field the call if that integration breaks.

Week 2: parallel environment setup and protocol mapping.

Stand up the replacement environment and configure it to support the protocols your partners require. Most modern SaaS MFT platforms support SFTP, AS2, and HTTPS-based file transfer natively; OFTP2 support is less universal, so verify before committing. Map each legacy integration to its replacement configuration. For SFTP integrations, this means user accounts, authentication method (password vs key), directory structure, and IP allowlisting. For AS2 integrations, this means trading partner certificates, MDN configuration, and the URL the partner will send to.

Don’t yet ask partners to cut over. Validate that the configuration is correct by running transfers in parallel with the legacy environment.

Week 3: partner outreach and coordinated cutover.

The migration success rate correlates strongly with partner outreach quality. An email blast to your SFTP partner list announcing a migration date will not produce a smooth cutover. What works: personal outreach to a named technical contact at each partner, shared new endpoint details and new certificate information well in advance, and a clear timeline with a legacy sunset date.

For AS2 partners, certificate exchange requires lead time — don’t schedule AS2 cutovers with less than two weeks of notice. For SFTP partners using key-based authentication, the new public key needs to be provisioned before the cutover date.

Run cutovers in tiers: low-volume, low-criticality integrations first. Use the first-tier cutovers to validate the runbook before moving high-criticality integrations.

Week 4: legacy decommission preparation and final migration.

Complete remaining partner cutovers. Validate that no production traffic is flowing to the legacy environment by monitoring connection logs on both systems simultaneously — the old and the new. Don’t decommission legacy infrastructure the day the last migration completes; keep it in a monitoring-only state for two weeks to catch any partner who reconnected to the old endpoint without notification.

Final decommission checklist: certificates revoked or documented as expired, credentials invalidated, server removed from DNS, firewall rules updated to block inbound connections to old IP, audit logs archived.

Common stumbling blocks

The integration nobody knew about. Every migration surfaces at least one partner integration that wasn’t in any documentation. The mitigation is to monitor legacy connection logs actively during weeks 2 and 3 so that unknown partners reveal themselves before the legacy system is shut down rather than after.

AS2 certificate mismatches. AS2 trading partner certificates have to match on both sides. Mismatches produce cryptic failures. Build time for certificate validation into the partner outreach timeline, and have a test-transfer capability that lets you confirm AS2 connectivity before the partner’s production cutover.

Shared service accounts on legacy SFTP. Many legacy MFT deployments used a single SFTP account shared by multiple internal systems, often with a password that’s been the same for years and is embedded in scripts no one has touched since the original implementation. Migrating these requires identifying every script that uses the account, replacing the shared credential with individual service accounts, and coordinating updates across multiple teams. Allow more time than you expect.

Internal file-drop workflows. Some integrations aren’t partner-facing — they’re internal scheduled tasks that drop files into a watched directory on the MFT server. These often aren’t documented at all and only reveal themselves when the legacy server is gone and the task fails silently. Inventory scheduled tasks on systems that have access to the legacy server before migration.

Success criteria

A successful migration meets all of the following:

• Zero partner-facing integrations using the legacy endpoint after sunset date
• All SFTP/AS2/OFTP2 integrations validated with test transfer on new platform before cutover
• Audit log continuity: no gap in transfer logging between legacy and new platform
• Legacy server decommissioned with credentials invalidated and firewall rules updated
• Named owner documented for every migrated integration
• TLS configuration on new platform meeting current standards (TLS 1.2 minimum, TLS 1.3 preferred, no weak cipher suites)
• MFA enabled on all administrative accounts in new environment

The migration is not complete when the last partner cuts over. It’s complete when the legacy infrastructure is decommissioned, documented, and no longer a surface for attack or accidental reconnection.