FreeBSD Colocation Migrations for New Server Moves

What this FreeBSD colocation migration covers

A FreeBSD colocation migration is a controlled move of your own hardware from one data center, cage, or rack position to another. This guide shows you how to prepare the server, coordinate remote hands, verify the power and network handoff, and bring the machine back online with as little disruption as possible.

You are working through a real production move here: a FreeBSD storage or application server is leaving one rack and landing in another, often because of cabinet changes, carrier changes, or a facility move. The goal is not just to power it back on. You want services reachable, ZFS data intact, and the new location verified before you close the old one.

If you are planning a larger infrastructure move, Hostperl’s Hostperl VPS plans can serve as a temporary fallback during cutovers, while this guide helps you protect the FreeBSD machine you already own in colocation.

Primary focus keyword: FreeBSD colocation migration

Focus intent: move production FreeBSD hardware safely between colocation locations without losing access, storage integrity, or network control.

Before you touch the hardware: decide the move model

Not every colocation move should follow the same playbook. A same-room rack shift is mostly about power, patching, and mounting. A cross-room move needs a network handoff plan. A full data-center migration needs change control, rollback timing, and a clear remote-hands runbook.

For FreeBSD servers, the main decision points are storage type, network dependency, and whether you can tolerate a short outage. ZFS systems usually move well, but only if you shut the server down cleanly and handle the disks with care. If the system runs jails or public services, plan for a temporary maintenance page or DNS cutover window.

• Same rack or same cage: confirm unit height, rail kit, PDUs, and cable reach.
• New cage or new hall: confirm cross-connects, switch ports, and IP handoff details.
• New facility: confirm carrier lead times, power limits, and the receiving site’s remote-hands process.

For operators weighing whether to keep the server on owned hardware or move workloads elsewhere, Hostperl’s dedicated server hosting can be a practical landing zone for workloads that do not need customer-owned iron during a migration.

Prerequisites on the FreeBSD server

Use FreeBSD 14.x or 13.5 with current security updates. This procedure assumes ZFS or UFS, physical colocation access, and a remote console path if the machine does not come up cleanly. If you rely on BMC, iDRAC, IPMI, or serial-over-LAN, test that path before the move.

On your local computer, start with the provider-assigned documentation IP only if you are connecting to a current staging or rescue environment. For the production machine, replace the example IP with your real public address.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation address. Replace it with the server’s real public IP from your colocation provider.

If your provider gives you a non-root login by default, use that account first, then elevate with su or doas.

ssh deploy@203.0.113.10

Run this on your local computer. Replace the example IP with your real server address and use the account your facility issued.

Check the FreeBSD release and inventory the server

On the VPS or physical server as root, detect the OS and confirm the platform before you change anything. FreeBSD uses its own service model, package manager, and update tools.

freebsd-version

You should see the installed release, such as 14.2-RELEASE. If the output is older than your support window, schedule a freebsd-update run before the move.

uname -a

This confirms the kernel, architecture, and host name. It is useful when remote hands report the wrong machine label.

df -h

zpool status

If your system uses ZFS, zpool status must report a healthy pool before shutdown. Any degraded or resilvering state should be fixed before transport. For restore discipline on FreeBSD systems that host sites, see FreeBSD WordPress hardening and recovery guide and the restore-oriented approach in PostgreSQL restore drills for safer VPS recovery.

Prepare a non-root admin and safe SSH access

If you still log in only as root, create a named admin account first. Keep the original root session open until the new login works from a second terminal.

On the VPS or server as root, create the account and set up key-based access. FreeBSD typically uses pw for account creation.

pw useradd deploy -m -s /bin/sh -G wheel

This creates the deploy account, adds a home directory, and puts it in the wheel group for administrative access.

passwd deploy

Set a password now so you have a fallback if key delivery is delayed. After SSH keys are confirmed, you can lock or retire password login if your policy requires it.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chown deploy:deploy /home/deploy/.ssh

Copy your public key into place. Replace the example key text with your actual key.

cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMexamplekeytextforhostperlcolocationmigration deploy@example.com
EOF
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Now open a second terminal on your local computer and test the login before touching root access.

ssh deploy@203.0.113.10

After you log in successfully, confirm privilege escalation.

su -
whoami

You should see root after switching. Only after this step should you consider tightening SSH policy. For broader FreeBSD operational recovery patterns, Hostperl also covers FreeBSD handoff and recovery workflows, which are useful if the move is part of a larger account transition.

Record the current rack, power, and network state

Before the server is powered down, document every cable and every dependency. In colocation, the most expensive mistake is usually not the move itself. It is losing track of which uplink, PDU feed, or management port belonged to which service.

Create a short move sheet with these items: server label, serial number, rack U position, PDU outlet, switch port, MAC address, assigned IPs, gateway, and any VLAN tags. If the server has two power supplies, label both feeds separately.

ifconfig -a

netstat -rn

ifconfig -a shows the interfaces and MAC addresses. netstat -rn gives you the current routing table, which is helpful when you need to confirm the correct default gateway after the move.

Schedule the shutdown and protect data

For a ZFS system, finish any writes, stop application services, and clear away maintenance noise before transport. If you host jails or databases, stop them in a controlled order.

service nginx stop
service mysql-server stop
service postgresql stop

Use only the service names that exist on your machine. If a service is not installed, skip it. For application servers that matter to your hosting business, a clean shutdown is the same discipline used in migrations like Docker Compose rollback practice and WooCommerce migration cutovers.

sync
shutdown -p now

Run this on the server as root. sync flushes buffers. shutdown -p now powers the machine off cleanly. Wait for the facility or BMC to confirm that all disks are idle before any physical handling starts.

Move the hardware with colocation-safe handling

Once the server is off, remote hands should disconnect power, label cables, and move the chassis using anti-static and lift-safe handling. If your hardware uses rails, do not drag it out by the bezel. Remove drive carriers only if the facility has a documented reason to do so.

If the machine includes HDDs or older SSDs, keep the chassis level during transport. ZFS can survive an orderly relocation, but it cannot fix damage from a dropped drive. If the system uses a single PSU, confirm the destination outlet can supply the expected draw before remote hands plug it in.

• Check that the new rack U matches the invoice and space allocation.
• Confirm front-to-back airflow is not blocked by blanking issues or cabling.
• Confirm the PDU circuit has spare amperage for boot surge.
• Verify the switch port is live and patched to the correct VLAN.

Bring the FreeBSD server up at the new location

After the chassis is mounted and cabled, power it on and wait for the console. If the machine does not reach the network, start with the simplest checks: link lights, console output, and interface naming.

ifconfig -a

Look for the expected interface name, link state, and MAC address. If the interface appears but no carrier is present, the issue is physical: port, cable, SFP, or patching.

service netif restart
service routing restart

Run these only after you know the config is correct. They reload the network configuration on FreeBSD. If you use static addressing, confirm the settings in /etc/rc.conf first.

Edit the network config if needed.

ee /etc/rc.conf

Example content for a static IPv4 setup:

hostname="server.example.com"
ifconfig_vtnet0="inet 203.0.113.10 netmask 255.255.255.0"
defaultrouter="203.0.113.1"
sshd_enable="YES"
zfs_enable="YES"

Save and exit the editor, then reload the network stack. Replace the documentation IPs with the actual values from your provider.

If your facility uses IPv6, add the corresponding address and default route. Do not guess the gateway; ask the provider or read the handoff sheet.

Validate storage, services, and boot persistence

After the system is reachable, confirm storage and boot behavior before you call the move complete. This is where many colocation migrations fail quietly: the server boots once, but the wrong pool, dataset, or service configuration is missing on the next reboot.

zpool status
zfs list

You want a healthy pool and the expected datasets mounted. If a pool imported read-only or a device is missing, stop and investigate the cabling before restarting applications.

service sshd status
service zfs status

On FreeBSD, service names must match the installed components. A healthy result should show the daemon running or the service enabled.

sysrc -a | grep -E 'hostname|ifconfig|defaultrouter|sshd_enable|zfs_enable'

This confirms the key boot-time settings are present. If they are not, fix /etc/rc.conf now so the next reboot does not undo the migration.

Test from a client and from the server

Run both local and remote checks. The server can report success while the outside world still cannot reach it.

On the VPS or server as root, confirm the address and listening ports.

sockstat -4 -l
sockstat -6 -l

These commands show services bound to IPv4 and IPv6 sockets. If a service is missing, start it or correct its config.

On your local computer, test SSH and HTTP if the server exposes a site.

ssh deploy@203.0.113.10
curl -I http://203.0.113.10

The SSH test confirms login from outside the facility network. The HTTP check should return a valid status line. Replace the example IP with the server’s real address.

If you expose a TLS site, test certificate identity too. A certificate mismatch after a move often means the DNS record or reverse proxy target still points at the old location.

openssl s_client -connect 203.0.113.10:443 -servername example.com 

Rollback and recovery if the move goes wrong

Every colocation move needs a rollback path. For a same-facility migration, that usually means keeping the old rack position available until the new one is proven. For a full facility move, the rollback may be a temporary relocation into a spare rack, a rescue VLAN, or a fallback Hostperl environment if your business can tolerate a short-term shift.

If the machine fails after arrival, use this order:

1. Check console output and power status.
2. Confirm link lights and switch patching.
3. Verify the interface name in ifconfig -a.
4. Compare /etc/rc.conf with the old move sheet.
5. Inspect zpool status for missing devices.

If you must roll back, power the system off cleanly, return it to the old rack or the known-good staging position, and restore the previous network path before retesting. Do not keep rebooting a machine with uncertain storage integrity.

Common failures and the fastest diagnostics

No SSH after the move: run ifconfig -a and netstat -rn. If the interface has no carrier or the gateway is wrong, fix the patching or /etc/rc.conf.

ZFS pool will not import: run zpool import and zpool status. If devices appear missing, stop and check whether the drive order changed or a cable was not reseated.

Services do not start: run service -e and service name status. If a service is disabled in rc.conf, enable it, then restart only after the config is correct.

Power is unstable: ask remote hands to confirm the PDU outlet and circuit load. Colocation migrations are often delayed by power planning, not software. For advance planning on cabinet space and electrical draw, Hostperl’s article on colocation rack units and power planning in 2026 is a useful companion.

Final verification checklist

Close the move only after you confirm the basics from both sides of the connection.

• SSH works from your local computer.
• The correct public IP answers on the new network path.
• zpool status reports a healthy pool.
• service sshd status shows the daemon running.
• sockstat -4 -l shows the expected listeners.
• The server survives a planned reboot without losing network or storage state.

For reporting to clients or internal management, capture the final move sheet, the post-move console note, and the service verification timestamps. That record saves time on the next relocation, especially if you manage multiple colocation assets across New Zealand or APAC sites through Hostperl.

FAQ

Can I move a FreeBSD ZFS server while it is running?

No. Shut it down cleanly before transport. ZFS protects data consistency, not physical shocks or loose cabling.

What should I test first after the server boots at the new site?

Check console output, interface carrier, ifconfig -a, and zpool status. Then verify SSH from an external client.

Do I need a fallback plan for a same-rack move?

Yes. Keep the old patching notes, power references, and a rollback window until the new location is stable.

What if remote hands connect the wrong port?

Use your move sheet to compare MAC addresses, switch labels, and PDU outlets. Correct the patch before restarting services.