Colocation Remote Hands Checklist for Safer Server Moves

Plan the move before anyone opens the rack

A colocation move usually fails before the first cable is touched. The real work is deciding what must stay online, what can be powered down, and what remote hands should confirm on-site. This tutorial walks you through a practical colocation remote hands checklist for Ubuntu Server in a live colocation environment, with safe sequencing, verification, and rollback steps.

You can use it for a single server move or a small fleet handoff in a data center. It fits customers who own hardware in a colocation cabinet, rely on remote hands for physical work, and need a clean handover after cable changes, power checks, or a cabinet migration. If your project also involves a new dedicated host, Hostperl’s dedicated server hosting and dedicated servers in New Zealand pages are useful references when you compare colo ownership against hosted hardware.

What this colocation remote hands checklist covers

This procedure focuses on the operational side of colocation: rack labels, power feeds, cross-connects, console access, IP reachability, and post-move health checks. It does not assume you are replacing hardware or re-architecting services. Instead, it gives you a repeatable way to ask remote hands for the right work, in the right order, with enough detail to avoid lockouts and surprise downtime.

• Single-server or small-batch colocation moves
• Power circuit checks and redundant PSU validation
• Switch-port and uplink verification
• Out-of-band access checks through IPMI or Redfish
• Post-move network and service smoke tests

If you are still deciding whether colo ownership or a managed platform is the better fit, Hostperl’s dedicated server buying guide can help you compare hardware control, support response, and operational overhead before you commit.

Before you begin: prerequisites and safe assumptions

This tutorial assumes an Ubuntu Server system already lives in a colo rack and you have root or sudo access over SSH. The physical side will be handled by colo staff or remote hands. Keep the original SSH session open until every new connection is confirmed.

On your local computer, start with the documented example below. The address 203.0.113.10 is a reserved documentation IP, so replace it with your server’s real public IP.

ssh root@203.0.113.10

If your provider uses a default non-root login, you may also connect as deploy with the same server IP once that account exists. For this tutorial, the first login is root so you can prepare the move safely.

Confirm the operating system and maintenance window

On the VPS as root, identify the platform before you make any changes. Ubuntu Server uses apt, systemd, netplan, and UFW, so this tutorial is written for that stack.

cat /etc/os-release

You should see Ubuntu Server release details, such as 24.04. If the machine is not Ubuntu Server, stop and use the matching maintenance procedure for that platform.

Now note the current state of the machine, including active users and open services.

who -a
systemctl --type=service --state=running | head -n 20
ss -tulpn

These commands show who is logged in, which services are running, and which ports are listening. That baseline matters if you need to explain a post-move issue later.

Prepare a non-root admin account before the move

Never ask remote hands to work against a server where only root SSH access exists. Create a sudo user first, then test it in a second terminal while the root session stays open.

On the VPS as root, create the admin account, set a password, and add it to the sudo group:

adduser deploy
usermod -aG sudo deploy
id deploy

The id output should show the sudo group. Next, prepare SSH keys for the new account.

On the VPS as root, create the SSH directory and set strict permissions:

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys

Paste the public key for the deploy user, then save and exit Nano with Ctrl+O, Enter, and Ctrl+X. Lock down ownership and permissions afterward:

chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Open a second terminal on your local computer and test the new account before changing root access.

ssh deploy@203.0.113.10

Replace 203.0.113.10 with the real server IP. Once logged in, confirm sudo works:

sudo -v
sudo whoami

You should see root from sudo whoami. Keep the original root session open until this test passes.

Build the remote hands checklist for the rack work

This is the part that saves time during a colo move. Give remote hands a short, exact sequence instead of a vague ticket. Use this as a template and replace the physical identifiers with your own rack data.

1. Confirm cabinet ID and unit position before touching power.
2. Photograph front and rear placement.
3. Verify both PSUs are plugged into separate power feeds.
4. Confirm switch port labels on the uplink and management cable.
5. Check that all cables are seated and labeled.
6. Report LED status for disks, NICs, PSU, and system health.
7. If the server was moved, confirm it powers on and reaches POST.
8. If the server has IPMI or Redfish, verify out-of-band access after the move.
9. Do not disconnect any production link unless the change window is open.
10. Send a completion note with timestamps and observed issues.

Keep the note practical. Ask for exact LED states, port names, and any error beeps or POST codes. That level of detail makes a move easy to audit.

Check power, storage, and out-of-band access

On the VPS as the non-root sudo user, verify that the server is ready for a power event or a rack move. Start with a quick hardware view.

sudo dmidecode -t system | sed -n '1,20p'
lsblk -o NAME,SIZE,MODEL,TYPE,MOUNTPOINTS
ip -br link

The output helps you identify the exact hardware, attached disks, and network interfaces. If the system uses RAID or ZFS, confirm the arrays or pools are healthy before the rack work begins.

sudo cat /proc/mdstat
sudo zpool status

Run only the command that matches your storage stack. A clean status here means you can separate a move issue from a pre-existing disk problem.

If your chassis has IPMI or Redfish, test it before the move. A colo shift is the wrong time to discover that the management network is disconnected.

ping -c 3 203.0.113.10
ssh root@203.0.113.10

Use the management IP, not the public service IP, for out-of-band access. If the management interface is on a separate network, your provider should give you that address in the handoff notes.

Confirm network labels, routes, and port reachability

For colo customers, the most common mistake is a correct server plugged into the wrong switch port. Verify your live network state before the change so you know what “good” looks like.

ip addr show
ip route show
ss -tulpn | grep -E ':(22|80|443|5432|3306)\b'

If you depend on IPv6, check that the address is present and the default route exists.

ip -6 addr show
ip -6 route show

For colocation migrations that involve a new cross-connect or carrier handoff, verify the switch-side labels too. A technician can only match your instructions if the ports are marked clearly at both ends. Hostperl’s colocation cross-connects and remote hands guide is a useful companion when you are documenting carrier-side work.

Apply the move with safe sequencing

If the server must be physically moved, schedule a maintenance window and stop only the services that truly need to pause. For many colo installs, that means databases or write-heavy jobs, not the entire box.

On the VPS as the non-root sudo user, check service names first so you can stop the right workloads:

systemctl list-units --type=service --state=running | sed -n '1,40p'

Then stop the selected service cleanly. Here is an example for PostgreSQL, which you should adapt to your own workload:

sudo systemctl stop postgresql
sudo systemctl status postgresql --no-pager

That status command should show the service as inactive. Do not power the server off until you have either flushed application writes or confirmed the service can tolerate the interruption.

Bring the server back and validate the rack work

After remote hands finish the physical job, bring the system back in a controlled order. Ask for the exact power-on result first: no POST errors, no unexpected disk lights, and no disconnected PSU feed.

On the VPS as root, once the machine is reachable again, verify the boot status and journal for obvious failures:

systemctl is-system-running
journalctl -p 3 -b --no-pager | tail -n 50

If the system reports degraded or the journal shows kernel or storage errors, stop there and inspect the logs before restarting services.

Next, confirm that your network came back with the right IP and route.

ip -br addr
ip route
ping -c 3 1.1.1.1

Then check the public-facing service ports again.

ss -tulpn

For HTTP or HTTPS services, run a real smoke test from your local computer:

curl -I http://203.0.113.10
curl -I https://203.0.113.10

Replace the example address with your server’s public IP. A successful reply should show a valid HTTP status code, such as 200, 301, or 302.

Check firewall and SSH access after the move

Colocation moves sometimes expose a stale firewall rule or a changed management address. On Ubuntu Server, UFW is the most direct way to confirm that SSH is still permitted.

sudo ufw status verbose

You should see an allow rule for SSH and any service ports you intentionally expose. If SSH was not allowed, add it before testing any lockout-prone change.

sudo ufw allow OpenSSH
sudo ufw reload
sudo ufw status numbered

Once the firewall is confirmed, open a new terminal and test SSH as the non-root admin again.

ssh deploy@203.0.113.10

Log in, run sudo whoami, and confirm you still have administrative access. Only after that should you consider disabling password login or root SSH, and only if your support process does not rely on root emergency access.

Rollback and recovery if the move goes wrong

If the server does not come back cleanly, use the safest path first. Restore the prior cabling or power arrangement before you change software settings. In colo work, most “software” failures are really a cable, feed, or port-label problem.

For a service that failed after the move, restart only the broken component once you have confirmed storage and networking are healthy.

sudo systemctl restart postgresql
sudo systemctl status postgresql --no-pager
sudo journalctl -u postgresql -b --no-pager | tail -n 50

If the problem is network reachability, inspect the interface, route, and DNS resolution in that order.

ip addr show
ip route show
resolvectl status

For kernel or disk errors, keep the machine in maintenance mode and capture the evidence before making more changes. If you need a second set of eyes, Hostperl’s support team can often help customers reason through a move window, a remote-hands handoff, or a rack recovery plan when the logs are clear and the timeline is documented.

Verification checklist from server and client

Use this final pass before you close the ticket:

• On the VPS: systemctl is-system-running returns running or a known acceptable state.
• On the VPS: ip -br addr shows the expected interface and IPs.
• On the VPS: ss -tulpn shows the expected listening services.
• On the VPS: journalctl -p 3 -b shows no new critical boot errors.
• On your local computer: ssh deploy@203.0.113.10 works again.
• On your local computer: curl -I http://203.0.113.10 or your application endpoint returns a valid status code.

When those checks pass, your colocation move is not just done. It is documented, reproducible, and supportable the next time the cabinet changes.

Frequently asked questions

What should I send remote hands before a move?

Send cabinet ID, U position, server label, power-feed details, switch-port labels, and the exact order of tasks you want completed. Add photos if possible.

How do I reduce downtime during a colocation move?

Verify out-of-band access first, stop only write-heavy services, keep the old session open, and do not change firewall rules until the server is reachable from a second terminal.

What if the server powers on but is unreachable?

Check link lights, interface names, route tables, and service status in that order. The problem is often a cable, port, or IP configuration issue rather than the application itself.

Should I disable root SSH after the move?

Only after the non-root sudo account works from a second terminal and you have a tested recovery method. Keep emergency access documented for support and incident response.

Can I use this checklist for a dedicated server too?

Yes. The physical steps are similar, but a dedicated server generally lives in the provider’s hardware lifecycle. Colocation adds rack ownership, remote-hands coordination, and cabling control.

Social copy

Twitter: Colocation moves fail less often when remote hands get a precise checklist. This Ubuntu Server tutorial covers cabling, power, network checks, SSH verification, and rollback. #Colocation #UbuntuServer #RemoteHands #Hosting Learn More: https://hostperl.com/kb/tutorials/colocation-remote-hands-checklist-safer-server-moves

LinkedIn: A good colocation move is mostly documentation and sequencing. This tutorial shows how to prepare remote hands, confirm rack power, validate network reachability, and verify the server after the move on Ubuntu Server. It also includes rollback steps if something comes back degraded. #Colocation #DataCenterOperations #UbuntuServer #Infrastructure Learn More: https://hostperl.com/kb/tutorials/colocation-remote-hands-checklist-safer-server-moves

Facebook: Planning a colocation move or rack handoff? This Ubuntu Server tutorial gives you a practical remote hands checklist, server-side verification steps, and recovery guidance if the move doesn’t go cleanly. #Colocation #RemoteHands #UbuntuServer #Hosting Learn More: https://hostperl.com/kb/tutorials/colocation-remote-hands-checklist-safer-server-moves