Hybrid and Private Migration

If diagnosis shows the work is still worth doing, the next decision is usually not “buy another year of reserved instances”. It is which workloads should leave the public cloud.

Hybrid and private setups answer the same class of problem: data is growing, the expensive lines are block storage and managed search, and the customer needs critical systems in an environment they control. Neither path means moving the whole company into a rack.

When a move is worth it

Signal	Closer path
No appetite for local hardware, or data and concurrency are still small	Cloud-only optimization first
A room or rack exists, data keeps growing, and cloud spend is already a real burden	Hybrid
Compliance or data-control requirements are strong, or cloud spend is high enough that a one-time hardware outlay pays back	Private

In practice, hybrid often means: core databases and search on physical hosts, public services and CDN still in the cloud, VPN in place of a dedicated cloud VPN VM. Private means the customer buys and holds the hardware for critical systems, with a small VPS left for overseas ingress if needed.

“Expensive” is not enough. Write frequency, the acceptable maintenance window, and whether someone on the customer side can operate the environment after cutover all belong in the proposal, not in a verbal aside.

What moves, what stays

Usual candidates to move: databases that keep generating block-storage bills, search that wants local SSD and RAM, and internal tools and backups that never needed a public edge.

Usual candidates to keep in the cloud: the public ingress, CDN, and bursty bandwidth that a small room cannot absorb.

Hardware is purchased and owned by the customer. Reallier advises on selection, plans the layout, deploys, and accepts. Ownership stays clear, and the customer still holds the full environment after the engagement.

The usual toolkit is chosen on site, not as a brand list: virtualization, ZFS / RAID, NAS backups, VPN, monitoring, databases, search, object storage. The bill of materials is in the diagnosis and the proposal, not in this page.

How cutover is staged

Work proceeds in stages. The old system stays until the new environment is verified.

1. Stand up the environment: virtualization, storage, network, and monitoring on the customer’s hardware, without touching production data.
2. Sync data: full backup, verify, then keep syncing. High-write systems get a dual-write window.
3. Canary: read-only or small traffic to confirm performance, access, and restore.
4. Cut over: switch ingress or the primary database inside a written maintenance window.
5. Keep rollback ready: the old environment is not torn down immediately. Rollback conditions, the decision owner, and the maximum reverse window are in the proposal.

Whether the business can stay up depends on the system, database size, write rate, and the window you can accept. Those three are written during assessment. If a silent cutover is not possible, that is in the proposal — not discovered on launch day.

Diagnosis is in Cloud Cost Diagnostics. The fuller schedule and document pack are in Technical Service Delivery Process. After sign-in, see the private-deployment guide, the onboarding checklist, and the acceptance criteria.

Who operates it afterwards

A migration delivery includes architecture notes, an operations manual, a change list, and a knowledge-transfer session. Monthly operations are optional: monitoring, backups, patches, infrastructure incidents, and inspection. They do not include new features, new systems, or a long-term on-site engineer.

The boundary is in the FAQ. A written SLA is in the signed-in operations note.