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.
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 center to the cloud in stages — each step with acceptance criteria, a rollback plan and a downtime window agreed in advance.
- 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
Legacy apps tied to a specific machine
Software installed by hand over the years, tied to a specific path, license 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.
Service
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.
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
-
01
Assessment
Inventorying the systems, measuring real usage and mapping dependencies between components.
-
02
Design
Designing the target architecture, choosing a migration approach per system and planning by stage.
-
03
Building the environment
Deploying the new infrastructure as code, with networking, security and links back to the old systems.
-
04
Pilot migration
Moving low-risk systems first to validate the process and measure real timings.
-
05
Cutover
A final sync and traffic cutover inside the agreed window, with a team standing by to roll back.
-
06
Stabilization
Close monitoring in the early period, configuration tuning and handover of operating documentation.
Customer
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 center
- 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.
