Migrating infrastructure to the cloud

One system at a time, always with a way back

HiTechCloud moves business systems from physical servers or an older data centre to the cloud in stages — each step with acceptance criteria, a rollback plan and a downtime window agreed in advance.

Survey your current systems Cloud Server
Starting point
Physical servers · IDC · Other clouds
Destination
HiTechCloud · AWS · Hybrid
How it is delivered
Phased, with a rollback plan
Downtime
Agreed in advance for each system
Overview

The risk in a migration is the data, not the servers

Rebuilding servers on a new platform is the easy part. The hard part is moving data that keeps changing, preserving integrations with outside systems, and guaranteeing you can get back to the old state if something goes wrong.

So we do not move everything in one night. The order follows dependency and criticality: low-risk systems go first to prove the process, and the core follows once everything is confirmed.

In most projects the old and new systems run in parallel for a period before full cutover. That cost buys you the ability to go back.

Common problems

Why migration projects tend to overrun

No dependency map

A service that looks standalone turns out to be called by three others. Discovering that after cutover is the most common cause of outages.

Legacy apps tied to a specific machine

Software installed by hand over the years, tied to a specific path, licence or IP address on the old server.

More data than the time window allows

The data to be synced exceeds the available bandwidth and downtime window, forcing a mid-project rethink.

Operations left as an afterthought

Once the move is done, monitoring, backups and permissions are never rebuilt on the new platform.

Services

Scope of work

Inventory and dependency mapping

Listing every server, service, database and the links between them — including the integrations nobody documented.

Designing the target architecture

Building on the new platform sized for real usage, rather than copying the old configuration across.

Data migration

Syncing data in several passes, with the final pass moving only the delta to keep downtime to a minimum.

Parallel running and testing

Running both systems in parallel, reconciling results and load testing before real traffic moves across.

Cutover and rollback

Cutting over inside the agreed window, with a rollback script prepared and rehearsed.

Setting up operations after migration

Rebuilding monitoring, alerting, backups, permissions and system documentation on the new platform before the project closes.

Networking and connectivity inside a data centre
Principles

No system moves until rollback has been rehearsed

Before every cutover, the rollback script is written and rehearsed in a test environment. If rollback does not work, the cutover is postponed.

  • A full backup is taken and verified as restorable before the cutover window.
  • The old system stays runnable throughout the monitoring period.
  • Rollback criteria are quantified, not decided on gut feel in the moment.
  • Every step is recorded so the next migration takes less time.
Process

The six steps of a migration project

  1. 01

    Assessment

    Inventorying the systems, measuring real usage and mapping dependencies between components.

  2. 02

    Design

    Designing the target architecture, choosing a migration approach per system and planning by stage.

  3. 03

    Building the environment

    Deploying the new infrastructure as code, with networking, security and links back to the old systems.

  4. 04

    Pilot migration

    Moving low-risk systems first to validate the process and measure real timings.

  5. 05

    Cutover

    A final sync and traffic cutover inside the agreed window, with a team standing by to roll back.

  6. 06

    Stabilisation

    Close monitoring in the early period, configuration tuning and handover of operating documentation.

Customers

Who this service is for

Businesses still running servers in the office

  • The hardware is out of warranty and spare parts are hard to find.
  • The server room depends on the building for power and cooling.
  • There is no plan for a disk or power supply failing over a weekend.

Businesses renting rack space at a data centre

  • The contract is ending and you are weighing up new hardware.
  • You want to reduce the trips someone has to make to the facility.
  • You need environments that can be stood up quickly for new projects.

Businesses on overseas cloud platforms

  • Currency movement makes the bill hard to forecast.
  • Latency to users in Vietnam is higher than you want.
  • You need invoices and contracts that meet Vietnamese requirements.
FAQ

FAQ

How long must the system be down?

It depends on the system. For a web application with a moderate database, the window is usually minutes thanks to multi-pass syncing. For very large datasets or legacy apps that cannot sync, the time is calculated and agreed in the plan.

Do we have to move to HiTechCloud infrastructure?

No. We deploy on AWS and other international platforms, or a hybrid of domestic and overseas infrastructure. The destination is chosen during consulting, on cost and legal constraints.

What if the legacy app no longer has a vendor behind it?

It can usually still be moved by preserving the runtime and migrating at the virtual machine level. We set out the limits and risks of that approach before starting.

Who is responsible if the migration causes an outage?

The migration plan, downtime window and rollback script are written into the contract along with each party's responsibilities. During cutover, engineers stand by to roll back if acceptance criteria are not met.

Start with a map of your current systems

Get in touch and HiTechCloud will survey your running infrastructure, map the dependencies and propose a phased migration.

Survey your current systems Cloud Server