What should I check before decommissioning the old server?

Confirm the license is active on the new server, every user can authenticate, automated transfers have run successfully at least once, and no partner or client is still connecting to the old address. Leave the old server powered off but intact for a short grace period before wiping it, in case something was pointed at it that you missed.

Migrating Your File Transfer Server to a New Machine (Without Losing Your License)

Q: Will migrating break my automated transfers and event triggers?

Not if they come across in the configuration export. Triggers, scheduled events, and alerts migrate with the rest of the config. The thing to re-verify by hand is anything that references the old machine specifically, such as a hardcoded hostname, a local path that differs on the new box, or a certificate tied to the old server name.

Moving a working file transfer server to a new machine (for a hardware refresh, a datacenter move, or a shift to the cloud) carries a specific worry that a normal server move does not: the license. Move it wrong and you're locked out of software you already paid for, on a deadline, with partners waiting.

That fear is well-founded but the fix is simple once you know the shape of it. A file transfer server migration is really two migrations wearing one coat: the configuration (users, folders, triggers, everything that makes it your server) and the license (the thing that lets the software run at all). Get both right, in the right order, and you can move with zero downtime and no lost work.

The short version

Export the full configuration from the old server. One file, everything in it.
Install the server on the new machine (same version, or take the chance to upgrade).
Import the configuration into the new install.
Transfer the license: release it on the old machine, activate it on the new one.
Run both in parallel, validate the new server, then cut over by repointing DNS or the firewall.
Decommission the old server once you've confirmed nothing's still connecting to it.

The order matters most in step 4. The license can't be active on two machines at once, so the rule is to release on the old machine before activating on the new one.

What "move all the settings" actually means

When people describe this task, they almost always list the same things. One customer planning a cloud move spelled it out:

"We are currently in the process of planning a move to Azure, which means new server setups. We currently use CompleteFTP Professional 8.2 and would like to upgrade to the latest version on a new Windows server. We would also like to keep all current settings (users, folders, alerts). Is this possible in any way?"

a Belgian distribution organization (EnterpriseDT support archive)

Users, folders, alerts. And underneath that headline list, the details that hurt if you miss them: permissions on each folder, event triggers and scheduled tasks, protocol settings, IP restrictions, TLS certificates, and SSH host keys. "All current settings" is a bigger set than it first looks.

This is exactly why you migrate by exporting the whole configuration rather than re-creating it by hand. A full config export carries all of it together, as one artifact, so the new server comes up as a faithful copy of the old one instead of an approximation you spend the next month patching. Another customer put the goal plainly:

"We are in the process of decommissioning this server and deploy a new one. Ideally we want this license transferred and ALL settings from the old server to the new server."

a retail organization (EnterpriseDT support archive)

A clean migration transfers the license and moves the settings, and neither half has to involve downtime.

Step 1: Inventory before you export

Before you export anything, spend twenty minutes writing down what this server actually does. Not because the export will miss it, but because your verification checklist later depends on knowing what "working" looks like.

Note the things that reference the machine itself, because those are what need a human eye on the new box:

Hostname and IP anywhere they're hardcoded (in triggers, scripts, or partner instructions).
TLS certificates tied to the old server's name.
Local file paths that might differ on the new machine.
Network shares and service-account permissions the server relies on.
Firewall rules and DNS entries that route partners to the current box.

Everything else rides along in the config export. This short list is what you'll double-check by hand after import.

Step 2: Export the configuration from the old server

On the old machine, export the full server configuration to a file. In CompleteFTP this is a single configuration backup that captures users, folders, permissions, events, and settings together. Save it somewhere off the old machine (that's the point of a backup).

Leave the old server running. You're not touching it yet. It keeps serving partners while you build its replacement, which is what makes the zero-downtime cutover in step 5 possible.

Step 3: Install on the new machine (and upgrade if you want to)

Install the server on the new machine. Here you have a decision: match the old version exactly, or take the migration as the moment to move to the current release.

A migration is a natural time to upgrade, because you're already testing everything on a fresh box while the old one stays live as a fallback. Plenty of customers combine the two, sometimes across a large version gap:

"We are in process of upgrading our SFTP tool from 8.3.xxx version to 13.xxx latest release. Please help us to get the detailed action plan along with data migration steps necessary for the successful migration. Also include license migration / installation steps."

an Indian airline (EnterpriseDT support archive)

Version 8 to version 13 in one move is workable: install the current version on the new machine and import the older configuration into it. Newer versions read older configs. The reason to test before cutover is that a large version jump can introduce settings that didn't exist in your old release, and you want those surfacing on a test box, not in production.

If you'd rather keep the migration and the upgrade as separate events, do the like-for-like version first, confirm it's stable, and upgrade later. Both are valid. Just don't discover a version-specific surprise after you've already retired the old server.

Step 4: Transfer the license (the part everyone worries about)

This is the step the whole task is anxious about, so here's exactly how it goes wrong and how to avoid it.

A perpetual license is tied to one active machine at a time. The failure mode is trying to activate on the new server while the old one still holds the license. You get the message that stops migrations cold:

"I am trying to install a licensed version of Complete FTP to a new server, but it looks like we've already used that license. We are no longer using the software on the old server."

a US logistics organization (EnterpriseDT support archive)

"We're no longer using it on the old server" is the key phrase, and the fix follows from it: release the license on the old machine first, then activate on the new one. Current versions have a self-service migrate-license function for exactly this. Release on the source, activate on the target, done, no support ticket required.

Two situations need a little more:

The old machine is already gone. If the old server died or was wiped before you released the license, you can't release it the normal way. Contact support and they'll reset the activation so you can register the new machine. This is routine, but it takes longer than releasing it yourself.

A very old version without the migrate-license feature. Older builds predate self-service license migration entirely, as one customer discovered:

"I'm attempting to move this install to a new server. I'm guessing that since we started on a version from 2015 the 'migrate license' feature is not enabled."

a US distribution organization (EnterpriseDT support archive)

Correct guess. If you're coming from a build old enough to lack the feature, support handles the transfer for you. It's still a clean move, it just runs through a person instead of a button.

Customers who plan ahead use the release-then-activate pattern deliberately as their migration mechanism, even across clouds:

"Now that we have up-to-date licenses, we have decided that the best strategy is to upgrade our servers to the latest version. This will allow us to use your release-license technique to do the migration from Azure to AWS."

a US medical-messaging organization (EnterpriseDT support archive)

Plan the move around that release-then-activate sequence.

Step 5: Run both servers in parallel, then cut over

Now you have two servers: the old one still serving traffic, and the new one configured, licensed, and idle. This overlap is your safety margin. Use it.

Validate the new server thoroughly while the old one still carries the load. Log in as a sample of real users. Fire any event triggers. Run an automated transfer end to end. Check the items from your step-1 inventory, especially anything referencing the old hostname or a certificate. You're looking for the small breakages now, while a rollback is free.

Running two instances side by side is a supported pattern, and it's sometimes needed for reasons beyond migration, like changing editions mid-flight:

"I need my current v9 Professional and my Enterprise running at the same time. I already have my new server running the latest version and was wondering if I need to install anything or just change the license on it."

a US healthcare organization (EnterpriseDT support archive)

When the new server passes your checks, cut over. Repoint DNS or update the firewall rule so partners reach the new machine instead of the old one. Because both servers hold the same configuration, connections simply start landing on the new box. There's no flag day where transfers stop.

Watch the old server's logs after cutover; traffic to it dropping to zero and staying there is the confirmation that the switch is complete.

Step 6: Decommission the old server (carefully)

Don't wipe the old machine the moment cutover looks clean. Power it off but leave it intact for a short grace period. The reason: something, somewhere, may still point at the old address, a partner script you didn't know about, a monitoring check, an internal job. If it surfaces, you want the old server recoverable, not gone.

Before you consider the migration truly done, confirm:

The license is active on the new server (and released from the old).
Every user can authenticate.
Automated transfers and triggers have each run successfully at least once.
No partner or client is still connecting to the old host.

When all four hold and the grace period's passed, retire the old machine.

Migrating to the cloud (Azure, AWS)

Moving to a cloud instance is the same six steps, not a different process. Export, install on the instance, import, transfer the license, run parallel, cut over. Several of the quotes above are cloud moves, and they follow the identical pattern.

The one area that needs extra attention is networking. A cloud instance's public address, its security-group or firewall rules, and the DNS record partners use all have to point at the new host before you retire the old one. Cloud migrations rarely fail on the file-transfer software; they trip on a security group that never got opened or a DNS record that still points at the old datacenter. Check the network path explicitly.

For air-gapped or offline environments, where the new machine can't reach a license server at all, offline activation exists for exactly this. It's common in defense and other isolated infrastructure, and support can walk you through the offline flow.

Frequently asked questions

Can I move my file transfer server license to a new machine?

Yes. A perpetual license can move between machines. The clean process is to release or deactivate the license on the old server, then activate it on the new one. The same key cannot be active on two machines at once, which is the most common cause of a failed activation on the new box.

How do I move all my users and settings to the new server?

Export the server configuration from the old machine and import it on the new one. A full configuration export carries users, folders, permissions, event triggers, alerts, and protocol settings together, so you rebuild the whole server from one file rather than re-entering everything by hand.

Can I upgrade to a newer version during the migration?

Yes, and a migration is a good time to do it. Install the current version on the new machine and import your existing configuration into it. The newer version reads the older config. Test the imported setup before cutover so any version-specific changes surface while the old server is still live.

How do I migrate the server with zero downtime?

Run both servers in parallel. Stand up the new server, import the config, and validate it while the old one keeps serving traffic. When you're satisfied, cut over by repointing DNS or the firewall rule to the new machine, then decommission the old server once you confirm nothing's still hitting it.

My license says it's already in use. What now?

That means the license is still registered to the old machine. Release it there first, then activate on the new server. If the old machine is already gone or unreachable, or the version predates the self-service license-migration feature, contact support and they'll reset the activation.

Can I migrate the server to Azure or AWS?

Yes. The process is identical to a physical move: export config, install on the cloud instance, import, transfer the license, and cut over. The extra care is networking. Confirm the instance's public address, firewall rules, and DNS point traffic to the new host before you retire the old one.

Will migrating break my automated transfers and event triggers?

Not if they come across in the configuration export, and they do. The thing to re-verify by hand is anything that references the old machine specifically: a hardcoded hostname, a local path that differs on the new box, or a certificate tied to the old server name.

Rehearse it before you cut over

Much of the worry around this task is worry about the license, and the license is the most solvable part once you know the rule: one active machine at a time, so release before you activate. The other risks are real too, the hostname and certificate references, the event triggers, the partner connectivity, but taken in order they become checklist items rather than surprises. Back up the configuration, restore it onto the new machine, run the two side by side, and cut over. Done that way a server migration is a planned, reversible move rather than a risky flag day.

CompleteFTP is built for this: the whole configuration lives in a single file you back up and restore onto the new machine, plus self-service license migration, side-by-side operation during cutover, and offline activation for isolated environments. It runs on Windows and Linux and reads older configurations into newer versions, so migrating and upgrading can happen in one move. It's the same server covered across our SFTP server guide. If you're planning a move, the free trial lets you stand up the target machine and rehearse the whole cutover before you touch production.