Prepare & deploy — CHT on AWS

This page covers everything that happens between "we've agreed on a design" and "the tenant is live": who is responsible for what, what the client must have ready before kick-off, and the sequence of deployment and cutover.

Read Plan your deployment first — the three design choices (account topology, network access, data hosting) must be settled before the work described here begins.

The timelines, RACI and landing-zone checklist below are the baseline assumptions for a greenfield CHT on AWS when Day-0 is complete at kick-off. Individual engagements stay flexible around that baseline (who implements the workload VPC as code, exact subnet layout, calendar length) without dropping the Day-0 bar or the phase order.

Shared responsibilities (RACI)

A CHT deployment is led and executed by Unique; the client's primary role during setup is to review and approve pull requests, provide access, and act as the approval authority for security and infrastructure decisions. The client owns the AWS account and everything that requires account-owner privilege or client-internal coordination (networking, identity federation, guardrails); Unique owns the application platform and its lifecycle. The table below summarises the split for the major workstreams.

*The client owns the account in which the cluster runs and grants Unique the scoped operational access needed to deploy and run the platform; Unique performs the work.

How to read "Responsible" vs implement. For account, network hub, guardrails, keys and IdP federation, the client truly owns the work. For the workload VPC, subnets and VPC Endpoints, Responsible means the client owns the landing zone in their account and must approve the design — Unique commonly implements that layer as PR-reviewed infrastructure-as-code under the client's approval authority (same pattern as the EKS/platform row). Who writes the Terraform is an engagement choice; it does not move account ownership or the Day-0 networking approval.

Effort & timeline, at a glance.

Setup: A greenfield deployment typically takes 8–14 weeks end to end (with about half a day per week from the client) — assuming all Day-0 requirements are provided at kick-off without later changes. The client-side foundation and approval work (accounts, network hub, VPC, endpoints, identity, keys, guardrails, security gates) is the critical path and is typically the longest pole; platform deployment onto a prepared landing zone is fast by comparison. Get the network, identity and security-gate prerequisites finalised early — they gate everything else.

Flexibility on the calendar. The 8–14 week band remains the planning baseline. Prior CHT deliveries show that incomplete Day-0 items (especially the security-gate list, guardrails, DNS, egress allow-list and connectivity) stretch Phase 1 and therefore the overall window — often by several weeks per late gate — without changing the phase order or the Day-0 checklist itself. Re-forecast only when a Day-0 item slips; do not silently compress platform phases to "make up" foundation delay.

Migration: Moving an existing tenant adds a further 8–14 weeks for data migration, security-gate iteration and environment stabilisation.

Prerequisites — what the client provides

Deployment is smooth only when these are ready. The Day-0 items must be settled before kick-off; the second group can follow within a week or two. Every security gate or guardrail added after kick-off extends the timeline by weeks, so finalise those lists up front.

Day 0 — required before kick-off

Ideally Day 0 — can wait 1–2 weeks

Landing-zone technical checklist

The concrete infrastructure that must exist (or be scheduled) in the workload account before platform deployment begins. The items below are the AWS reference landing zone (see Reference architecture); exact subnet naming and tier count may be adapted to the topology chosen in Plan your deployment, as long as the same capabilities are covered (private cluster path, private PaaS reachability, inspected egress for the short external allow-list, management access).

Do not route AWS-service traffic through the firewall. AWS services (foundation-model, object storage, key management, container registry, document extraction, monitoring, session management) are reached over private VPC Endpoints inside the VPC. The egress allow-list is only for the short list of external hostnames — container registries, GitHub, the client IdP and SaaS connector domains. Conflating the two is the most common preparation mistake — see Reference architecture for the full endpoint list.

Deployment sequence

Once the landing zone is verified, the platform is deployed in a repeatable order. Each phase gates the next. The durations below are approximate and assume the prerequisites are ready; the client-side foundation and approval work is the main driver of the overall 8–14 week setup window.

Sequencing tip. Foundation-model access enablement and IdP federation both involve client-side approvals that can take time. Start them during Phase 1 rather than waiting for the phase in which they are consumed — doing so keeps them off the critical path.

Migrating an existing tenant

When an existing tenant is being moved into a client-hosted account (rather than a greenfield deployment), the sequence above still applies, with two additions. Migration typically adds a further 8–14 weeks on top of the setup window for data migration, security-gate iteration and environment stabilisation:

• Data migration — existing relational, search, vector and object data is exported from the source environment and imported into the target data services during Phase 3, with a validation pass before cutover. The co-existence of the two tenants (source and target) must be planned carefully.

• Cutover window — a defined window in Phase 5/6 during which traffic is switched to the new tenant. Plan a rollback path in case verification fails.

Next

Once the tenant is live, day-two concerns — availability targets, monitoring, log drain, access and guardrail-drift handling — are covered in Operate.