Planning a government or national data centre
A national data centre brings together services that may previously have been run by separate departments. The building and equipment are only part of that change. The project also needs clear ownership of applications, networks, information, operating procedures and service recovery. Start by agreeing who makes decisions and what the first operating stage must deliver to its users.
Define the first services and their owners
Create a service register before fixing the final capacity. For each service, record its owner, current hosting location, demand, dependencies and acceptable recovery objectives. Distinguish the time needed to restore a service from the amount of data loss that its owner can accept. Those are separate requirements and can lead to different backup and replication arrangements.
Identify services with common dependencies such as identity, naming, time, shared storage and connectivity. Moving an application while leaving a critical dependency unplanned can create a failure even when the new servers work correctly. Give each dependency an owner and a migration decision. Keep uncertain future demand separate from the opening load so the first phase has a credible operating purpose.
Choose a site that supports the service
Review power availability, connection dates, flood exposure, access, security boundaries and fibre routes together. A cheap plot can become difficult if it needs lengthy network works or has no practical route for replacement equipment. Check the ground conditions and levels before setting the building arrangement. Plant yards, fuel deliveries, maintenance access and expansion space are part of the site requirement.
Set security zones around the actual work people perform. Visitors, deliveries, maintenance staff and operators need controlled routes that can be used safely. Coordinate access control with emergency escape and emergency response. The design should make legitimate work manageable; procedures that require constant exceptions tend to weaken control during normal operations.
Separate resilience from duplication
Duplicating equipment inside one building does not protect against every site-level event. If the service requires another location, define its role and the failure scenarios it covers. Check geographic and infrastructure dependencies, including power, communications and staff access. A second address alone does not establish independent recovery capability.
Decide which systems remain active, which are on standby and how data moves between locations. Include bandwidth, latency, application behaviour and recovery procedures in that decision. Backups need separate recovery testing; replication can copy an unwanted change as readily as a wanted one. The owner should approve the recovery sequence and the evidence required to show it works.
Turn procurement into clear interfaces
Write the boundary between civil works, incoming supply, power systems, cooling, racks, networks and applications. Name who designs each interface, who supplies it, who installs it and who tests it. Record expected inputs and acceptance criteria. An interface marked only as being by others leaves a predictable gap when several contracts meet.
For tenders with formal eligibility requirements, confirm the contracting arrangement before submission. G2MAX does not hold formal certifications. Where a tender requires them, a qualified local partner signs and stamps, and the proposal states that arrangement. This should sit alongside a clear responsibility table so the client knows who is accountable for each part of delivery and operation.
Stage migration and acceptance
Move services in groups that can be tested and rolled back. Start with an agreed pilot, verify the operating process and then increase the scope. Define who can approve each migration, when the old environment can be retired and how users report issues. Keep change records that connect an application move to its infrastructure and security changes.
Acceptance needs more than successful equipment start-up. Test power transfers, cooling recovery, alarm handling, access control and the service recovery procedures. Use agreed loads and safe methods with clear stopping criteria. Retain measured results, settings and unresolved items, then obtain acceptance from the people responsible for operations rather than relying only on a construction completion milestone.
Budget time for the operating team
Bring operators into design reviews while decisions can still change. Plan training, spare parts, maintenance arrangements and document access before handover. Practise routine isolation and emergency response with the actual site team. A good handover makes normal operation repeatable and makes abnormal events easier to understand, with drawings and records that match the installed facility.
Questions
Is a disaster-recovery building enough to protect services?
No. Recovery also needs suitable data copies, connectivity, application arrangements, procedures and tested ownership. Building readiness and service readiness are different acceptance points.
Should every department move on the same date?
Only if dependencies and rollback plans support that decision. Staged moves usually make faults and ownership easier to identify and control.
Who signs off the first operating stage?
Agree this in the project governance. Facility operators, service owners and the accountable client representative should accept the evidence relevant to their responsibilities.
Start with your four inputs: site, IT load, available power and target date. The estimator gives a browser first pass; an engineer checks the design.
Try the estimator →Send your four inputs →