Dedicated Server Handover Checklist: What to Test in the First 24 Hours

A dedicated server should not move from “provisioned” to “production” simply because it boots and accepts SSH connections. The first 24 hours are your acceptance window: the best time to confirm that the machine you received matches the order, behaves normally under load, has working recovery paths, and can be monitored before real workloads make troubleshooting harder.

The goal is not to benchmark every component. It is to establish a clean baseline and find discrepancies early enough to raise them with the provider while the deployment is still simple. Treat the handover as an acceptance test with recorded results, not an informal login-and-look-around exercise.

1. Start With the Order, Not the Operating System

Before changing packages, partition layouts, firewall rules, or application configuration, compare the delivered server with what you actually rented. Provisioning mistakes are easier to identify before you modify the system.

Verify the following against the order or service description:

• CPU model and expected processor count;
• installed RAM;
• number, type, and approximate capacity of storage devices;
• RAID configuration, if RAID was ordered;
• network port speed;
• included traffic or bandwidth commitment;
• assigned IPv4 and IPv6 addresses;
• data-center location;
• operating system and installation method;
• remote management or rescue access included with the service.

Do not treat small-looking discrepancies as automatically harmless. A different SSD model, missing disk, unexpected CPU, or lower negotiated network speed can change performance, redundancy, or capacity assumptions later.

Record the provider’s service identifier, server serial or asset identifier if exposed, assigned addresses, network details, and support contact path. You will want this information immediately available during an incident.

2. Inspect the Hardware the OS Can See

Next, verify that the operating system sees the expected resources. This is different from checking the invoice: you are confirming what the running machine can actually use.

CPU and memory

Confirm the processor model, logical CPU count, total memory, and whether anything looks unexpectedly unavailable. On Linux, standard tools such as lscpu, free, dmidecode where permitted, and information under /proc can provide the initial inventory.

Do not turn the acceptance test into a synthetic benchmark contest. Unless your rental contract promises a specific benchmark result, the useful question is whether the hardware matches the specification and remains stable under representative load.

Storage devices

List every physical and logical device. Confirm capacities, partitions, filesystems, mount points, and RAID membership before storing important data.

If SMART data is available, inspect drive health information and error logs. SMART is useful evidence, but a single health indicator is not a guarantee that a disk cannot fail. Treat it as one part of the acceptance check rather than a substitute for redundancy and backups.

For software or hardware RAID, verify the array state explicitly. A server can boot while an array is degraded. Finding that condition after migration defeats much of the point of redundancy.

3. Check the System Logs Before Creating Your Own Noise

A freshly provisioned server gives you a useful opportunity: there should be relatively little application noise in the logs.

Inspect the current boot and kernel messages for repeated storage errors, filesystem problems, memory-related warnings, network interface resets, machine-check events, unexpected device failures, or services repeatedly crashing and restarting.

One warning does not automatically mean the server is defective. Hardware, firmware, drivers, and distribution defaults can all generate benign messages. Repeated errors, I/O failures, resets, or faults that correlate with load deserve investigation before production deployment.

Save the relevant output if something looks wrong. A support ticket containing timestamps, device names, error messages, and reproduction conditions is far more actionable than “the server seems unstable.”

4. Verify Network Configuration From Both Directions

A successful SSH connection proves surprisingly little about the network. Test the server as both a destination and a source.

Confirm the configured addresses, subnet or prefix information, default routes, DNS resolution, and IPv6 connectivity if IPv6 is part of the deployment. Check the negotiated interface state and speed where the operating system exposes them.

Then test the paths your workload will actually use. That may include:

• connectivity from your administration network;
• connectivity to databases, storage, APIs, or other infrastructure;
• IPv4 and IPv6 separately;
• DNS resolution using the intended resolvers;
• connections from important client regions;
• large transfers or sustained traffic where throughput matters.

Latency should be judged against the location and workload you selected, not against an arbitrary universal threshold. A server intended for users in the same region has different expectations from one used for replication across continents.

Do not confuse a speed test with a bandwidth guarantee

Throughput testing is useful for identifying an obviously constrained or misconfigured connection, but one test cannot establish the permanent capacity of the provider’s network. Results depend on the remote endpoint, route, congestion, protocol, test duration, and other conditions.

For a more controlled test, tools such as iperf3 can measure throughput between endpoints you control. Run tests only against systems you are authorized to use and avoid generating disruptive traffic.

Record the baseline. Even if the result is not contractually meaningful, it gives you something to compare with future troubleshooting.

5. Test Storage Without Destroying the Installation

Storage deserves more than a capacity check because many server problems first become visible under sustained I/O. But testing must be deliberate: destructive disk tests can erase the operating system or RAID metadata.

Start with non-destructive checks. Verify expected devices, RAID health, filesystem status, available space, mount options, and SMART information where supported. If you run an I/O workload, use a dedicated test file or disposable filesystem rather than a raw production device unless you specifically intend a destructive test.

Watch the system while the test runs. You are looking for more than peak throughput: monitor for I/O errors, unexpected device resets, severe instability, RAID degradation, kernel errors, and abnormal behavior that persists after the workload stops.

Delete test files afterward and confirm that temporary testing has not filled a filesystem that the operating system needs.

6. Apply a Controlled Load and Watch for Instability

A machine that is stable while idle may fail when CPU, memory, storage, and network activity increase. Before production, apply a controlled workload that exercises the resources relevant to your intended use.

The purpose is not to maximize a benchmark score. It is to answer three practical questions: does the machine remain responsive, do system logs stay clean, and does the server recover normally when the test ends?

Avoid immediately combining every possible stress test at maximum intensity. Testing components in stages makes failures easier to isolate. If a storage test causes errors, for example, you want to discover that before simultaneously saturating CPU and network resources.

Keep an administration session available during testing and know how to reach the server through the provider’s out-of-band console or rescue environment if it stops responding.

7. Prove the Recovery Path Before You Need It

Remote recovery is one of the most important parts of a dedicated-server rental because you cannot walk into the data center and attach a keyboard yourself.

Before production, determine exactly what happens when normal remote access fails. Depending on the provider, recovery may involve an IPMI-class management interface, KVM console, serial console, rescue environment, remote reboot function, or a support request.

Test the recovery mechanism if doing so is supported and safe. Confirm that you can authenticate, identify the correct server, and reach the controls or console you expect. If access requires a separate customer portal, make sure the appropriate operators have access before an outage occurs.

Also document the provider escalation path. Know where to open an infrastructure ticket, what service identifier to provide, and which issues qualify for emergency escalation under your service terms.

8. Secure Administrative Access

Provider provisioning credentials should be treated as bootstrap credentials, not necessarily as the final access model.

Change provider-supplied passwords where applicable. Establish individual administrative accounts, install the required SSH public keys, and remove credentials that are no longer needed. Restrict exposed management services according to your operating model.

Before disabling any existing login method, open a second session using the replacement method and verify that it works. Locking yourself out while “hardening” a remote dedicated server is an avoidable handover failure.

Review listening services and firewall rules as well. A default installation may expose services that your production role does not require. Remove, disable, or restrict unnecessary services rather than assuming the provider’s base image matches your security policy.

9. Patch the Base System Before Adding the Workload

Check the operating system’s configured repositories and update policy, then install the security and maintenance updates appropriate for your deployment process. If an update requires a reboot, the handover period is usually a better time to discover reboot problems than after production traffic arrives.

After rebooting, verify networking, storage, RAID state, remote access, and critical logs again. A successful first boot does not prove that the machine will return cleanly after maintenance.

This is also the point to remove temporary test packages you do not intend to maintain.

10. Configure Monitoring Before Production

Do not migrate first and promise to add monitoring later. At minimum, establish visibility into the resources whose failure would make the server unavailable or unreliable.

The exact monitoring stack is less important than coverage. Depending on the workload, useful signals include CPU utilization and load, available memory, filesystem usage, storage latency, disk or RAID health, network errors, interface traffic, service availability, and system reboots.

External monitoring matters too. A monitoring agent running on the server cannot reliably tell you that the entire server or its network path has disappeared. Use an independent system to test the services that clients depend on.

Test alert delivery. A dashboard turning red without reaching an operator is visualization, not an incident-response mechanism.

11. Verify Backup and Restore, Not Just Backup Configuration

If the server will hold data that must survive hardware loss, establish the backup path before migration. Do not assume RAID, redundant drives, snapshots, or a provider recovery environment are equivalent to an independent backup.

Confirm the destination, credentials, retention policy, encryption requirements, and available capacity. Then run an initial backup or a representative test and restore something from it.

The restore test can be small, but it should prove that the backup is readable and that operators know how recovery works. If your recovery design depends on rebuilding the entire machine, document the required operating-system image, configuration, secrets, application artifacts, and data sources.

12. Create a Handover Record

By the end of the acceptance period, you should have a compact record of what was delivered and what you tested. This becomes the baseline for future incidents and migrations.

Area	Acceptance check	Record
Hardware	CPU, RAM and storage match the order	Detected inventory
Storage	Devices and RAID healthy; no unexplained I/O errors	Array and health status
Network	Expected addresses, routes and connectivity work	Configuration and baseline tests
System	Clean boot and stable controlled load	Relevant logs and test notes
Access	Production admin method and recovery access verified	Access procedure, not passwords
Security	Bootstrap credentials replaced and unnecessary exposure removed	Configuration status
Monitoring	Internal and external checks active	Monitored services and alert path
Backup	Backup completes and sample restore succeeds	Destination and restore procedure
Provider support	Escalation route identified	Service ID and support procedure

What Should Stop the Production Launch?

Not every imperfection requires rejecting a server. A minor configuration issue you control may be easier to correct than to reprovision the machine. The important distinction is between a known, understood configuration task and an unresolved infrastructure problem.

Delay production deployment when you find unexplained hardware errors, degraded storage redundancy, repeated disk or network resets, missing ordered resources, persistent instability under reasonable load, unreliable administrative access, or no workable recovery path.

Network performance also deserves escalation when it is materially inconsistent with the service you ordered, but collect evidence first. Record timestamps, source and destination, test method, routes where relevant, and repeated results. This helps distinguish a server-side or provider-side problem from a limitation elsewhere on the path.

A Practical First-24-Hours Sequence

1. Before modifying the server: compare the delivered specification with the order and capture the initial inventory.
2. Before installing applications: inspect disks, RAID state, system logs, interfaces, routes, and remote recovery access.
3. Before migrating data: test storage and network behavior, apply controlled load, patch the operating system, and perform a clean reboot.
4. Before accepting production traffic: establish final administrative access, firewall rules, monitoring, alerting, and backups.
5. Before declaring handover complete: test a restore, save the acceptance record, document provider escalation, and resolve unexplained errors.

The Handover Is a Baseline, Not a Certification

No 24-hour test can prove that a dedicated server will never experience a disk failure, network incident, hardware fault, or operating-system problem. That is not the objective.

A good handover establishes something more useful: you know what hardware was delivered, how the machine behaved before production, how to reach it when normal access fails, what will alert you when conditions change, and how to recover the workload if the server is lost.

Once those checks are complete, production deployment begins from a known state rather than an assumption that “provisioned” means “ready.”