Coordinating Partners Through Your Migration

"We sent the notice six weeks ago." "To which address?" "The one in the register." "The one that belonged to someone who left last spring?" Half of a transfer migration is not yours to do. The endpoint is saved in a partner's script. The fingerprint is pinned in their known-hosts file. The rule in their firewall names your address. All of it must change on machines you will never log into. People who do not work for you must make those changes, on a schedule their change-control board owns. And here is the part that stings: your migration is, to every partner, an interruption. Nobody on their side gets rewarded for helping you move servers. They get punished if their files stop flowing.

So partner coordination is not a courtesy layered on top of the technical plan. It is the technical plan, for everything on the far side of the wire. This article, part of our Workload Migration series, is the working kit. It covers what every partner needs to hear, a notice template to copy, and test windows partners will actually use. It covers risk-based sequencing and an escalation ladder for the partner who never answers. It covers fallbacks for the go-live morning that meets reality. None of it asks a partner to care about your project. It only asks them to keep their files flowing, which they already want.

Why Partners Decide Whether Your Cutover Works

Every flow has two halves, and the inventory earlier in this series split them. There is configuration on your side, which you can change at will. Then there is configuration on the partner's side, which you can only ask about. The partner-side list is short but absolute. It includes the endpoint name or address their automation connects to, and the host key or certificate their client trusts. It includes the credentials they present, and the firewall rule through which their traffic (or yours) is permitted. If any of those must change and the partner does not act, that flow breaks at cutover, full stop. No amount of excellence on your side substitutes. I have watched a flawless cutover sit dead behind one partner's firewall line.

The firewall rule deserves special emphasis because it is the change partners most often forget they even have. Years ago their security team approved "allow transfers to 203.0.113.25" and everyone moved on. Your cutover notice must explicitly surface it: if your firewall names our address, add the new one. Add, never replace. The old address must keep working until decommissioning, both for stragglers and for your own rollback path. A partner who tidily deletes the old rule the day they add the new one has quietly disabled your ability to fall back.

The good news, also from earlier in the series: the endpoint-stability toolbox shrinks the ask. A stable service name, a carried-over host key, and an unchanged folder layout can reduce many partners' action list. It can shrink to a single firewall line — or to nothing at all. The coordination effort concentrates on whatever you could not keep stable. The best notice says "no action needed" and means it.

One caution from the field: a partner's confirmation covers only what that person can see. A partner can test successfully from their office network and still fail in production. Their automation may run from a hosting provider whose firewall also pins your address. That is a second allowlist their own IT team forgot existed. The question that surfaces this early is worth adding to every notice. "Does your transfer to us pass through any third party who might also need to know? Is it a hosting provider, a managed service, or an integration vendor?"

What Every Partner Needs to Hear

Every notice, whatever its format, must answer seven questions — and the second one is the most neglected:

• What is changing — in one sentence, without internal project jargon.
• What is not changing — credentials, paths, names, schedules, protocols. This list does more to prevent panic and mistaken "fixes" on the partner side than everything else combined.
• When — the date and time window, with timezone stated.
• What they must check or do — concrete per-pin actions: the firewall add, the fingerprint update, the switch from hardcoded address to service name.
• The new identity facts — addresses, and fingerprints or certificate details if they change, presented so they can be verified, not just accepted.
• The test window — where and when they can prove their side works before the real night.
• Who to call — a monitored contact and the fallback promise: the old platform remains available until a stated point.

The Notice Template

Here is a template with synthetic values; adapt freely. Note how it leads with the no-action case, keeps every action conditional ("if your firewall…"), and never asks anyone to blindly accept a security warning:

Subject: Action may be needed -- our file transfer service is moving

To: the technical contact for the Bayside Logistics file exchange

What is changing
  On Saturday [date], starting 22:00 our local time, our transfer
  service moves to a new platform. The service name stays
  transfer.example.com. If you connect by that name and pin nothing
  else, no action is needed -- but please read the checks below.

What is NOT changing
  - Your account name, password, and keys
  - Folder paths, file names, and schedules
  - Supported protocols and settings

Checks and actions
  1. FIREWALL: if your rules allow our address 203.0.113.25, ADD
     198.51.100.40 alongside it now. Please do not remove the old
     address until we confirm decommissioning.
  2. HOST KEY: our SFTP fingerprint is unchanged. If your client
     reports a changed fingerprint at any point, do NOT accept it --
     contact us instead.
  3. ADDRESS: if your automation connects to a hardcoded IP rather
     than transfer.example.com, switch to the name before [date].

Test window
  The new platform is open for testing at test.transfer.example.com
  from [date] to [date]. Your production credentials work there.
  Please upload one file named TEST_bayside.txt and download one
  file from your outbound folder, then reply to confirm.

If anything fails after the move
  Contact [name / phone / mailbox], monitored through the cutover
  weekend. The previous platform remains available as a fallback
  until [date].

One notice is not a campaign. Each later message is short — the template above is the long one — and the working cadence looks like this per wave:

Six weeks out       Full notice (template above) to every partner in
(a quarter for       the wave. Ask for an acknowledgment by a named date.
 slow movers)
Four weeks out      Chase non-acknowledgers -- start the ladder (below).
Two weeks out       Reminder to all; test-window results reviewed;
                    anyone untested gets a personal nudge.
A few days out      Final confirmation: date, time, contact, fallback.
Cutover day + 1     "Complete -- please verify your side" note, plus
                    your own day-after sweep of expected arrivals.
Decommission        Closing note: old platform retired; old firewall
                    rules and cached fingerprints may now be removed.

This cadence is lifted from the same playbook as protocol retirements. The companion article on partner communications for retiring FTP shows the specialized version, where the ask is bigger than an address.

Two Directions, Two Different Asks

Notices go wrong when they ignore which way each flow points. For inbound flows — the partner connects to you — the asks are the ones the template covers. They are the endpoint name, your server's identity, and their outbound firewall rules toward you. For outbound flows — you connect to them — the picture mirrors. Your new platform will initiate from a new source address, so their inbound allowlist must admit it before your first push. That is the single most commonly missed line item in migration notices. It is easy to forget that your source address is part of their security configuration. And the pinning reverses too: it is now your new platform that must trust their host key. That is why the inventory article had you record the keys you pin as carefully as the keys pinned against you. Write the outbound partner's notice accordingly: "our transfers to you will arrive from 198.51.100.40 beginning [date]; please allow it alongside the current address."

Test Windows Partners Will Actually Use

A test window converts your riskiest unknowns into answers, weeks early, at a time nobody is panicking. Can they reach the new platform? Will their client trust it? Do their credentials work? Expose the new platform on a test name, with production accounts already provisioned, and ask each partner for one round trip. Have them connect, authenticate, and upload a file named with an agreed TEST_ prefix so no automation ingests it. Have them download something from their outbound folder, and reply to confirm. That one round trip exercises the address path, the allowlist, the identity pin, the credentials, and the folder layout. It covers every partner-side failure mode in one five-minute exercise. The general craft of running one is in partner test windows. Five minutes in the test window, or a fortnight after the weekend.

Make the test window observable from your side, because partners say "we tested, all fine" with varying reliability. The new platform's activity log tells you who genuinely connected, from which address, and what they did. On a target such as Sysax Multi Server, per-account activity logging gives you exactly that record. Per-account IP allow and block rules let you keep the test endpoint scoped to the partners invited into each wave. Record each result in the register — tested, date, from address. The fact that matters is "tested from the address their production traffic actually uses." Their test from a laptop on guest wifi proves less than they think.

Acme's test window looked complete: thirty-one of thirty-three partners had uploaded their TEST_ file and replied. On cutover night one of the thirty-one failed anyway. Their engineer had tested from the office, in good faith. But their production job ran from a hosting provider whose firewall also named Acme's old address. Nobody on the partner's side had known that rule existed. The activity log settled it in a minute: the test had come from an office address, the production attempts from the hosting range. The flow went back to the old platform under per-partner grace. The hosting provider added the rule the following week. Acme added "from which address?" to the tested column and the third-party question to the notice. The next migration's test window asked both up front.

Sequencing Partners by Risk

In a wave-based cutover, order is a safety device. The first wave exists to find the flaws in your runbook while the stakes are low. The last wave inherits a runbook that has survived several rounds of contact with reality. Sequence with a simple scoring pass over the register:

Three refinements. First, put a handful of daily flows in the first wave even though rarity feels safer. You want fast feedback, and a monthly flow tells you nothing until it next runs. Second, treat internal "partners" — other teams whose systems exchange files with the platform — as wave-one material. They follow the same notice-test-verify sequence, but you can walk to their desk. That makes them the cheapest place to debug the process itself. Third, the mega-partner exception: a partner large enough to dictate terms will migrate on their date, not yours. Find that date early and design the waves around it rather than pretending you control it. Their date is weather; plan around it, do not argue with it.

The Unresponsive Partner Ladder

Every migration has partners who never reply. Treat non-response as a standard case with a standard ladder, not a personal frustration. Climb it early, because each rung takes days. In my experience the full ladder has never taken less than a month. The silence is almost never personal: the mailbox belongs to a role nobody fills anymore. Here are the rungs:

1. First notice to the registered technical contact, with a requested reply-by date.
2. Reminder two weeks later to the same contact, plus any partner portal or ticket channel they operate.
3. Phone call to the technical contact. A surprising number of migrations are unblocked by one call — the mailbox was a departed employee's.
4. Internal business owner. Find whoever in your organization owns the relationship — the account manager, the buyer, the analyst whose report depends on the file. Have them raise it through their channel.
5. Commercial escalation. The partner's account or relationship manager hears "your files to us stop working on [date] unless someone technical talks to us."
6. Deadline with a stated consequence — and a grace path: their flow stays on the old endpoint, per-flow, under monitoring, for a defined grace period. Their problem is now contained, and your migration proceeds without them.
7. The stop. At the end of grace, the flow stops when the old platform retires — announced repeatedly, never a surprise. It is remarkable how quickly a partner who ignored five notices calls once a transfer actually fails. Reserve this rung for low-criticality flows, with the business owner's explicit sign-off recorded in the register.

Fallbacks for the Go-Live That Meets Reality

However good the notices, some partner will fail on the night. Think of the firewall change that was "definitely done," or the client that pins more than they knew. Decide the fallback moves in advance, so the on-call person executes rather than improvises:

• Per-partner grace: the failing partner's account stays enabled on the old platform. Their flow reverts there with one register update, and everyone else's cutover proceeds. This is the workhorse fallback and the reason the old platform stays fully able to serve until decommissioning.
• Wide revert: if failures are systemic rather than individual, the DNS flip reverses. That means five minutes back to the old platform if you lowered TTLs as the cutover article describes. The triggers for that bigger decision belong to validation and rollback, decided before the night, not during it.
• The day-after sweep: the loudest failures announce themselves; the dangerous ones are silent. The morning after each wave, compare expected arrivals against actual for every migrated flow. That is the discipline of freshness checks for expected files. Call every partner whose file is missing before they discover it themselves. For your own outbound pushes, make failure loud. A scheduler like Sysax FTP Automation can send notifications when a transfer fails. That turns a partner's missed allowlist change into a same-hour phone call instead of a next-week mystery.

Run It Like a Project, Keep It Like Evidence

Give the register five more columns — notified, acknowledged, tested, migrated, verified, each with a date. Then partner coordination becomes a status you can read at a glance rather than a feeling. Keep the sent notices and the replies, and put the contact you finally reached back into the partner record. Then the next campaign starts from a live address rather than a memorial one. The article on keeping partner documentation current covers that habit. Months later, when a partner insists "you never told us," the comms log answers quietly. If credentials do change as part of the move, tie the handover into the practices from partner credential lifecycle so secrets move through channels worthy of them. If this migration is also the moment you formalize how partners connect in general — standards, onboarding, offboarding — that larger program is our B2B partner exchange series.

Wrapping Up: The Partner Track Is the Critical Path

Technical work compresses under pressure; partner responses do not. Start the notices before the target platform is even finished. Sequence the waves so the early ones teach and the late ones inherit. Climb the ladder early for the silent, and write the fallbacks down while everyone is calm. Then the go-live becomes what it should be. Most partners notice nothing, a few need the grace path, and nobody needs a miracle. The shape those waves fit into is in cutover strategies. The evidence that lets you finally retire the old platform is in validating the migration.

Frequently Asked Questions