Dedicated Server Acceptance Checklist Before Production

Your hosting provider has delivered a new dedicated server, installed the operating system, and shared administrative credentials. Before sending production traffic to the machine, confirm that the delivered configuration matches your order and that essential services are ready.

A dedicated server acceptance checklist provides a structured way to verify hardware, storage, network connectivity, security, performance, backups, and operational responsibilities before approving the server for production.

Unlike shared or VPS hosting, dedicated server hosting provides exclusive access to physical CPU, RAM, and storage resources. This gives growing businesses greater control over their server environment, including the flexibility to install custom software and configure infrastructure for specific workloads. Such control also introduces operational responsibilities, making acceptance testing an important part of production preparation.

Why A Dedicated Server Acceptance Checklist Matters

A successful server deployment does not automatically mean the machine is ready for production. Provisioning covers hardware preparation, operating system installation, network configuration, and administrative handover. Acceptance verifies whether those components meet the agreed requirements.

For example, a dedicated server might have the correct processor and memory but an incorrect storage layout. Another server might support normal SSH access but lack a working emergency recovery procedure, and catching these issues before production reduces the risk of unexpected downtime and operational disputes.

Begin with the approved order, network design, application requirements, and support agreement. Use these documents as the baseline for evaluating the delivered system. The Atlantic.Net dedicated server hosting page provides information about available infrastructure options, but the signed order should determine your acceptance criteria.

Provisioning timelines are separate from acceptance testing. Standard configurations may take only a few hours, while customized deployments require additional preparation. Atlantic.Net explains these differences in its dedicated server provisioning time guide.

Confirm The Delivered Server Matches Your Order

The first stage of acceptance focuses on hardware, operating system compatibility, and storage configuration. Even minor differences between ordered and delivered specifications might affect application performance, capacity planning, or future maintenance.

Hardware Specifications And Physical Condition

Compare the installed processor, physical CPU cores, memory, storage devices, and network interfaces with your purchase agreement.

For example, a server ordered with an AMD EPYC processor, 128 GB RAM, and two 1.92 TB enterprise SSDs should provide those exact resources. On Linux, tools such as lscpu, free -h, and lsblk help identify hardware specifications without requiring extensive benchmarking.

Physical inspections should include the server chassis model, asset tag, serial numbers, and physical condition. If your infrastructure is hosted remotely, request hardware inventory or inspection evidence from the provider.

Hardware health deserves equal attention. RAID controller warnings, disk errors, memory faults, and abnormal temperature readings might indicate problems despite a successful operating system boot.

Supporting evidence should include an inventory report, hardware health summary, or provider confirmation. Any discrepancy between the delivered hardware and approved configuration should appear in the acceptance record.

Operating System And Software Compatibility

The installed operating system should match the version specified in your order and support the applications you plan to run.

Review the OS edition, kernel version, licensing status, security patches, and support lifecycle. Time synchronization, network drivers, and successful restart behavior also matter because problems in these areas often become visible after applications enter production.

Application compatibility deserves special attention. Suppose your business depends on accounting software certified for a specific Windows Server version. Installing a newer operating system without vendor certification might create compatibility or support problems even if the installation succeeds.

The same principle applies to Linux applications requiring specific database versions, runtime libraries, control panel components, or hardware drivers.

Record the installed software baseline and identify who owns future updates. Operating system acceptance should reflect application requirements rather than assuming the newest available version is always appropriate.

Storage Layout And Disk Health

Storage verification should examine more than total disk capacity. The delivered server should have the agreed RAID configuration, filesystem layout, partitions, mount points, and usable capacity.

Consider an online business ordering two SSDs configured as RAID 1 for a production database. If the hosting provider installs both disks as independent volumes, the hardware quantity matches the order, but the required redundancy is missing.

The customer should report the discrepancy and request correction before approval.

Review disk health, filesystem permissions, encryption settings, and storage controller alerts. For environments handling sensitive data, confirm encryption key ownership and recovery procedures.

RAID improves availability for certain disk failures, but independent backups remain necessary for protecting against accidental deletion, corruption, and other data loss events.

Verify Network Connectivity And Administrative Access

A dedicated server needs more than a working internet connection. The network configuration should match the approved architecture and provide access only to intended services.

Network Settings, Reachability, And DNS

Compare the server’s IP address, subnet, gateway, DNS resolvers, network interface speeds, and VLAN assignments with the agreed configuration.

Where separate public and private interfaces exist, confirm their intended roles. Network verification should include approved inbound connections, outbound connectivity, and access to internal services such as databases or backup destinations.

A successful website connection does not prove the complete network configuration is correct. Testing blocked connections is equally important, especially for management interfaces and private application services.

DNS records also deserve attention when the server replaces existing infrastructure. Document the current records, intended destination addresses, and ownership of DNS changes.

For migration planning, teams sometimes lower DNS TTL to 300 seconds at least 48 hours before cutover, depending on existing TTL values and resolver behavior. Detailed DNS cutover procedures belong in the separate server migration plan. Acceptance should confirm the correct network settings and ownership of changes.

Administrative And Emergency Recovery Access

Administrative access should work through the approved authentication method. For Linux servers, key-based SSH authentication, named administrator accounts, and controlled sudo privileges provide clearer accountability than shared credentials.

Direct root access through SSH should be restricted when a verified alternative administrative method exists. Changing the SSH port might reduce automated scanning noise, but strong authentication and properly configured firewalls provide more meaningful protection.

Emergency access is equally important.

A server with functioning SSH access might become unreachable after a firewall mistake or operating system failure. Confirm whether the provider supplies an out-of-band console, rescue environment, or support-assisted recovery process.

The acceptance record should identify the responsible team, emergency contact, and access recovery procedure. Avoid disabling the final working administrative connection before verifying an alternative.

Review Security Settings Before Production

Dedicated server security depends on correctly configured access controls, authentication, patching, and network protection.

Start by reviewing firewall rules against the approved application design. Public services should expose only required ports, while database and management interfaces should remain restricted to authorized networks.

Consider a dedicated server hosting a customer-facing application and a MySQL database. The application requires public HTTPS access through port 443, but the database should accept connections only from approved internal addresses.

If port 3306 is publicly accessible without an approved requirement, the server fails the intended security configuration even when the application works correctly. Resolving the exposure before processing live data reduces unnecessary risk.

Security acceptance should also cover TLS certificates, certificate renewal responsibility, SSH keys, operating system patching, endpoint protection, and audit logging.

Where the agreement includes DDoS protection, confirm the protected IP addresses and response procedures. Dedicated infrastructure provides resource isolation, but isolation alone does not establish compliance or complete security.

Organizations handling payment card information should identify applicable PCI DSS requirements and record supporting control evidence. Advanced security features should match the actual workload and contractual scope.

Keep evidence of security reviews, including firewall approval records, certificate checks, and relevant access-control test results.

Check Server Performance And Workload Readiness

Dedicated servers provide exclusive hardware resources, but dedicated hardware does not guarantee high application performance under every workload.

Performance testing should establish whether the delivered server meets agreed infrastructure requirements. Relevant measurements include CPU utilization, available memory, storage latency, network throughput, and hardware error rates.

For high-traffic websites, examine response times and errors under representative request volumes. Database workloads might require storage performance measurements and query response checks.

For example, an AMD EPYC server with sufficient RAM might still experience slow database queries because of inefficient indexing or application configuration. Such problems need investigation, but they do not automatically indicate defective hardware.

Use agreed test conditions and document the results. Avoid uncontrolled stress testing or relying on arbitrary public internet speed tests to judge the provider’s network.

The acceptance record should distinguish hardware or network problems from application issues. This provides a useful performance baseline for future troubleshooting and capacity planning during peak times.

Validate Backups, Monitoring, And Recovery

Reliable backups and monitoring arrangements are essential for maintaining a production server. Acceptance should confirm that the agreed systems work and that someone is responsible for responding to failures.

Verify Backup Integrity With A Restore Test

A scheduled backup job does not prove successful data recovery.

Review backup frequency, retention periods, protected directories, database consistency requirements, encryption, and storage locations. The 3-2-1 backup rule provides a useful reference for maintaining separate copies, although the final design should follow contractual recovery requirements.

Perform an appropriate restore check before approving the server.

For example, restore a test database into an isolated environment and validate the recovered records. For file-based applications, recover a representative directory and inspect its contents and permissions.

Save the backup timestamp, restore result, completion time, and tester details. These records establish whether the recovery procedure produced usable data.

Recovery objectives also matter. The team should understand the agreed recovery point objective and recovery time objective, along with any limitations observed during testing.

Include complete disaster recovery exercises and multi-node failure drills in separate recovery procedures. Dedicated server acceptance should establish a working backup and restore process for the delivered environment.

Confirm Monitoring And Alert Delivery

Monitoring systems should collect relevant server health and environmental metrics, including CPU load, memory usage, storage capacity, hardware faults, and network errors.

Application logs and service availability checks provide additional information about workload health. Depending on the server’s role, monitoring tools might also track database connections, application response times, or certificate expiration.

A dashboard displaying normal performance does not establish an effective alerting process.

Generate a safe test notification and confirm delivery to the designated engineer or support team: record alert ownership, escalation procedures, and coverage outside normal business hours.

This helps ensure future warnings reach someone responsible for investigating the problem.

Confirm Provider And Customer Responsibilities

Operational handover is incomplete until your team understands who manages the server after delivery.

With unmanaged dedicated server hosting, the provider generally handles physical hardware and underlying facility connectivity. At the same time, the customer manages operating system maintenance, software updates, security configuration, and application support unless the agreement specifies otherwise.

Managed hosting shifts selected responsibilities to the provider based on the purchased service scope. Atlantic.Net’s server management services describe management options worth comparing with your agreement.

Shared responsibilities deserve particular attention.

For example, a hosting provider might install operating system security patches while the customer’s application team approves the maintenance window and verifies application functionality afterward.

Both teams need clear responsibilities for this process. Similar arrangements might apply to firewall changes, monitoring alerts, backups, and TLS certificate renewals.

Review the applicable service level agreements, support contacts, escalation procedures, and maintenance notifications. An uptime commitment of 99.9% or higher should never be assumed without checking the signed SLA and relevant exclusions.

Documentation should cover critical server configuration details, access controls, operational procedures, and application dependencies.

If the project involves server migration, the written plan should identify the old server, target environment, DNS records, cron jobs, database connections, and rollback responsibilities.

Migration duration and old-server retention should follow workload requirements rather than universal assumptions such as two to six weeks for migration or seven days of continued operation.

Keep detailed migration activities separate from the acceptance process.

Document Outstanding Issues And Approve The Server

A dedicated server might satisfy every hardware and infrastructure requirement while the application remains unready for production.

For example, the delivered machine might have the correct CPU, storage, operating system, network settings, and firewall configuration, but the application might fail database connection testing because of an incorrect connection string.

Infrastructure acceptance establishes whether the delivered server meets its agreed specifications and operational requirements. Application release readiness requires separate validation of application functionality, integrations, and live data migration.

The final acceptance decision should reflect the severity of unresolved issues.

Incorrect RAID configuration, missing recovery access, failed backup restoration, or unexpected public exposure should normally prevent production approval.

Minor documentation gaps might qualify for conditional acceptance when the service owner approves a resolution plan and assigns a completion date.

Supporting evidence might include inventory reports, RAID screenshots, network test results, backup restoration logs, and provider support tickets. Store these records in a shared location accessible to authorized stakeholders.

Dedicated Server Acceptance Checklist: Example Verification Record

The following example shows how a customer might document acceptance testing for a dedicated server running Ubuntu 24.04 with an AMD EPYC processor, 128 GB RAM, and mirrored SSD storage.

The Owner column identifies the responsible person or team. Result indicates Pass, Fail, or Pending, while Unresolved Issue describes any remaining problem.

In this example, the server passes its hardware, operating system, network, and backup checks. The storage configuration fails because RAID 1 is missing, while firewall approval remains pending.

The service owner should withhold production approval until both issues are resolved and the affected checks pass.

A dedicated server is ready for production acceptance when the delivered specifications match the order, essential operational checks pass, and responsible teams agree on maintenance and support ownership.

Keeping supporting evidence and unresolved issues in one acceptance record gives your team a clear basis for production approval and future troubleshooting.