Moving Partners Off FTP: Communication That Works

Partner flows are the part of an FTP retirement you control least. You can convert your own scripts on a Tuesday afternoon, but a partner cutover needs another organization to read an email, find the right person, change their settings, test, and confirm — all on their schedule, for your benefit. That asymmetry is why partner workstreams run the longest in any retirement plan, and why they fail differently: not with error messages, but with silence.

The remedy is communication treated as craft rather than formality. This article is the partner playbook from our Retiring Plain FTP series: what to prepare before the first email, three notice templates you can copy — initial, reminder, and final — the test-window routine that makes cutovers boring, a tracker that shows exactly who stands where, and an escalation ladder for laggards that gets flows moved without damaging relationships your sales team spent years building.

Why Partner Moves Fail

Partner migrations fail in predictable ways, and every one of them is a communication defect rather than a technical one:

• The notice reaches the wrong inbox. The contact on file is an employee who left, a generic accounts-payable address, or the salesperson who signed the deal. The email is technically delivered and practically nonexistent.
• The ask is vague. "We are upgrading our FTP; please switch to SFTP" gives the partner's admin nothing to act on — no host, no credentials process, no date. Vague requests get filed as someday-work, and someday never schedules itself.
• There is no test path. Asking a partner to change production settings cold, with no rehearsal, guarantees they wait until forced — because from their side, an untested change to a working flow is pure risk.
• One email, then silence, then a surprise. A single notice months before a cutover is forgotten by everyone including the sender. The partner's first real notification becomes the transfer failure itself.

Invert each defect and you get the playbook: find the right human, make the ask concrete, provide a rehearsal, and communicate on a drumbeat until the tracker says done.

Before the First Notice: Get Your Side Ready

Nothing goes out until a partner who says "great, let's switch today" could actually do it. That means the secure endpoint is live and tested — phase zero of the retirement plan — and the supporting pieces exist:

• The protocol offer. Decide what you are offering before partners ask. SFTP is the usual first choice because nearly every partner's tooling speaks it; FTPS suits partners standardized on certificates. Serving both costs little when the endpoint is a multi-protocol server — Sysax Multi Server presents FTPS, SFTP, and HTTPS from the same host — and letting the partner pick removes their easiest reason to stall. The reasoning behind per-partner choices is covered in the partner protocol decision.
• The credentials process. Decide how new passwords or SSH keys reach partners. Never inside the notice email itself — use a separate channel: a phone call, your existing secure portal, or a split delivery (username by email, password by phone). Write the process down so every partner gets the same one.
• A support path. A named mailbox or person, stated response time, and someone empowered to do a screen-share session with a struggling partner admin.
• The connection information sheet. One page with every technical detail their admin needs. This is the document that separates a five-day cutover from a five-week one.

Here is the sheet's skeleton — attach it to every notice:

CONNECTION INFORMATION — SECURE TRANSFER ENDPOINT

Host:            transfer.example.com   (unchanged)
Protocols:       SFTP (port 22)  or  explicit FTPS (port 21)
Your account:    [username]             (unchanged)
Credentials:     delivered separately via [channel]
Folder layout:   unchanged — same paths as your current FTP flow

SFTP host key fingerprint (verify on first connect):
  SHA256:[fingerprint-here]
FTPS certificate: issued by [CA name] to transfer.example.com

Firewall note:   your outbound rules may need port 22 (SFTP)
                 or 21 + passive range [range] (FTPS) permitted
Test window:     [start] to [end] — test files welcome any time
Production cutover deadline:  [date]
Support:         [mailbox / phone], response within [n] business hours

Two details in that sheet quietly prevent most support tickets. Publishing the host key fingerprint — the identifier SFTP clients show on first connection — turns an alarming "unknown host" prompt into a checkbox exercise. And the note that folder layout and account names are unchanged answers the partner admin's first real question: "how much of my configuration survives?" The answer "all of it except the protocol" is what makes partners cooperative.

Finding the Right Human

Every partner has two relevant contacts, and notices need both. The relationship contact — account manager, vendor manager, whoever owns the commercial relationship — ensures the request carries weight and nobody is blindsided. The technical contact — the admin who will actually change the settings — is the one who can say done. Start with whatever contact you have, copy your own account manager for the partner, and put a forwarding request in the first line of the notice: "if you are not the right person for file transfer settings, please forward this and tell us who is." Update the tracker with the confirmed technical contact the moment one replies; that name is the single most valuable field you will collect.

The Initial Notice

Send it as early as the retirement plan allows — partner lead time is the program's longest pole, so this email starts the clock. Keep it short, concrete, and free of fear: this is a routine security upgrade, not an emergency. The template:

Subject: Action needed: our file transfer connection is moving to
         an encrypted protocol — deadline [date]

Hello [name],

If you are not the right person for your company's file transfer
settings, please forward this and let us know who is.

We exchange files with you today over plain FTP. As part of a
security upgrade, we are retiring unencrypted transfer and moving
all partners to SFTP or FTPS — the encrypted equivalents. Your
folders, account name, and file workflow stay exactly the same;
only the connection settings change.

What we need from you:
  1. Reply to confirm the right technical contact.
  2. Pick your protocol: SFTP (most common) or FTPS.
  3. Test during the open window: [start]–[end]. Send any test
     file; we will confirm receipt the same business day.
  4. Cut your production transfers over by [date]. Plain FTP is
     disabled after that date.

The attached sheet has every technical detail (host, ports, host
key fingerprint). New credentials arrive separately via [channel].
Questions or want a working session? Contact [support mailbox /
phone] — we are glad to walk through it together.

Thank you,
[name, role, company]

Notice what the template does: the forwarding ask is first, the unchanged parts are stated explicitly, the actions are numbered and small, and the deadline appears twice. One notice per flow, not per company — a partner with three distinct flows gets three trackable asks, otherwise two convert and the third is forgotten by both sides.

The Test Window: Rehearsal Before Cutover

The test window is a standing invitation: the new endpoint is live in parallel with the old one, and partners can rehearse whenever suits them. Their production flow stays on FTP until they choose to switch, so testing carries zero risk — which is precisely the property that gets busy partner admins to act. Run it with a small routine on your side:

1. When a test file arrives, confirm the same business day, by name: "received your test at [time], contents intact — you are clear to cut over." Fast confirmation converts momentum into cutover.
2. For pull-based partners, stage a test file for them to download and confirm.
3. Watch your server logs during each partner's first attempts. Failed connections tell you the story before the partner emails: a firewall still blocking outbound port 22 on their side, a mistyped hostname, an IP allowlist on your side missing their new source address.
4. Mark the tracker "tested" only on evidence — their confirmation plus your log entry.

Most partner cutovers, in practice, are one successful test followed by a same-week settings change. The window's job is to make that first success effortless.

The Reminder

Halfway between the initial notice and the deadline, everyone who has not tested gets a reminder. It is shorter, references the first notice, and — its real work — states their current status plainly, because "our records show you have not yet tested" is what moves a task from someday to this-week:

Subject: Reminder: file transfer cutover deadline [date] — we have
         not yet seen a test from [company]

Hello [name],

A quick follow-up on our move from plain FTP to encrypted transfer
(first notice sent [date]). Our records show your account has not
yet tested the new connection.

The test window remains open through [end date]. It takes most
partners under an hour: connect with the attached settings, send
any test file, and we confirm the same day. Your production flow
is untouched until you choose to switch.

After [deadline], plain FTP is disabled and transfers using the
old settings will stop working — we want to make sure that date
passes without any interruption on your side.

Need help or a quick working session? [support mailbox / phone].

Thank you,
[name]

The Final Notice

Two weeks or so before the deadline, the holdouts get one unambiguous message. No new information — just consequence, date, and help. Copy the relationship contacts on both sides at this stage, because the remaining names are no longer a technical queue; they are a business risk list:

Subject: Final notice: plain FTP is disabled on [date] — action
         required to avoid interrupted transfers

Hello [name],

This is the final notice before our unencrypted FTP service is
permanently disabled on [date].

From that date, connections using your current plain-FTP settings
will fail, and file exchange between our companies will stop until
the new settings are in place. The encrypted connection is ready
now and takes under an hour to adopt — settings attached, and we
will confirm your test the same day.

If there is a constraint on your side that makes [date] genuinely
impossible, contact us this week so we can discuss options — but
we cannot leave the unencrypted service running by default.

We would much rather help you cut over this week than troubleshoot
a stopped flow after the deadline. Reach us at [support mailbox /
phone].

Thank you,
[name]

Tracking Partner Progress

The tracker is a few columns added to the retirement inventory, one row per partner flow, with a state that only moves on evidence:

The distinction between cut over and verified matters more than it looks: a partner can switch their nightly job and still have a forgotten weekly report running over old settings. Your server's per-account logs settle it — a partner is verified when their secure sessions appear and their plain-FTP sessions stop for a full cycle of every flow they run. These states feed the weekly governance count from the retirement plan, and the same routine — sheet, window, tracker — is worth keeping after retirement, since every future partner connection is a small onboarding. Our trading partner onboarding article turns that routine into a standing process.

Handling Laggards Without Burning Bridges

Some partners will still be on FTP as the deadline approaches. Before escalating, remember what their silence usually means: not refusal, but a queue — their admin is fielding a dozen other companies' migrations plus their own work. The ladder below applies pressure gradually, keeps the relationship intact, and never lets an administrator make a revenue decision alone:

1. Re-target the message. Silence often means wrong inbox, even now. Call the relationship contact and get a fresh technical name before assuming reluctance.
2. Offer to do it together. A thirty-minute working session — their admin, your admin, screen share — converts most laggards on the spot. Effort on your side is cheaper than delay on theirs.
3. Escalate relationally, not technically. Your account manager asks their business owner for a named date. A commercial nudge from the relationship channel outperforms a third technical email every time.
4. Grant a time-boxed exception if the reason is real. A partner mid-merger or mid-platform-change may genuinely need weeks. Document it: reason, named owners on both sides, firm end date, sign-off from your risk owner. The shutdown date holds for everyone else. The discipline of documented, expiring exceptions is the same one used for legacy devices in the containment article.
5. Let the business make the final call. If the deadline arrives with a partner unmoved and unexcepted, the decision to let their flow stop belongs to the sponsor, made in advance and in writing — never a surprise the partner discovers, and never an administrator's solo judgment call. In practice, the final notice plus a pending stoppage produces a cutover within days; partners move quickly when the alternative is explaining an interrupted flow to their own leadership.

After the Last Partner

When the tracker shows every partner verified or formally excepted, the partner workstream is done — and the program's hardest external dependency is behind you. What remains is proving the whole estate clean: the final sweep, the monitoring for stragglers, and the evidence pack, covered in proving plain FTP is actually gone. Keep the templates and the connection sheet in your runbook; they are the reusable half of this project, and the next protocol migration — whenever and whatever it is — will start from them.

Frequently Asked Questions