News & Insights
Cloud Migration in Malaysia: A Step-by-Step Roadmap
A cloud migration in Malaysia now involves a decision that did not exist a few years ago: whether to run in-country, in the region, or across both. This roadmap sets out the phases in order, the choice to make for each workload, what Malaysian regulation requires along the way, and the costs that surface after the first invoice.
It is written to be used with any provider or enterprise cloud partner. Nothing in it depends on which platform you choose, because the sequencing errors that damage migrations are the same everywhere.
The 6 Phases of a Cloud Migration
1. Assess: Inventory the estate. Applications, servers, databases, integrations, licences, data volumes and dependencies. Classify data by sensitivity and by any residency obligation attached to it. The output is a list of workloads with an owner and a dependency map, not a server count.
2. Business case: Establish why. Exiting a data centre lease, retiring hardware at end of life, needing elasticity for a seasonal peak, or a specific capability you cannot run on-premises. A migration without a named driver becomes a lift-and-shift that costs more per month than the estate it replaced.
3. Design the landing zone: Accounts and subscriptions, network topology and connectivity back to your sites, identity, logging, guardrails, tagging and cost allocation, backup and recovery. Build this before the first workload moves, because retrofitting governance across a live estate is the most expensive rework in cloud.
4. Migrate in waves: Group workloads into waves by dependency and risk. Start with something real but not critical, so the process is tested before the stakes rise. Each wave gets its own test plan, cutover plan and rollback plan.
5. Optimise: Right-size after observing real usage, apply commitment-based discounts once demand is understood, remove what nothing is using, and re-architect the workloads whose costs are structural rather than incidental.
6. Operate: Ongoing security, patching, cost governance, monitoring and support. This is a permanent operating model, not a project close-out, and it needs an owner named before go-live.
Phases 1 to 3 are where migrations are won. Organisations that compress them to reach a moving date pay for it in phases 5 and 6.
Choosing a Migration Strategy for Each Workload
Six options, applied workload by workload rather than to the estate as a whole.
| Strategy | What it means | Use when | Trade-off |
| Rehost | Move the workload as it is, onto cloud infrastructure | The deadline is fixed, or the application is stable and unlikely to change | Fastest route, and it carries existing inefficiencies onto a metered platform |
| Replatform | Minor changes, such as moving to a managed database or container service | A small change removes a large operational burden | Modest effort for a real reduction in maintenance |
| Repurchase | Replace with a software-as-a-service product | The application is a commodity, such as email or a standard finance package | Less control over configuration, and a data migration of its own |
| Refactor | Re-architect the application for cloud-native services | The application is strategic and its current design limits the business | Highest cost and longest timeline, so it needs a business case of its own |
| Retire | Switch it off | Nothing depends on it, which is more common than expected | Requires an owner willing to confirm the decision |
| Retain | Leave it where it is, for now | Latency, licensing, residency or an imminent replacement makes moving wasteful | Keeps a second environment running, so it must be a decision rather than a deferral |
Most estates end up with a mix, and hybrid is a legitimate destination. The mistake is applying one strategy to everything because it was the one in the proposal.
Data Residency and Regulation for Cloud Migration in Malaysia
In-country infrastructure changed the residency conversation. The AWS Asia Pacific (Malaysia) Region became generally available on 22 August 2024 with three availability zones, under the API name ap-southeast-5, and other hyperscalers have announced or are building Malaysian capacity. Running in-country is now an architectural choice rather than a constraint, which means it has to be justified per workload rather than assumed.
Financial institutions have specific obligations. Bank Negara Malaysia’s Risk Management in Technology policy document, updated on 1 June 2023, added requirements covering the adoption of cloud services: internal policies governing cloud use, due diligence on the cloud service provider, minimum contractual clauses covering information security and operational standards, a documented risk assessment before critical systems go to cloud, and a risk-based consultation and notification process with the Bank for public cloud carrying critical systems. The assessment has to consider where the infrastructure sits and the legal and geopolitical risks attached to that location, not only the technical controls.
Personal data adds a second layer. Under the PDPA, an organisation remains responsible for personal data it moves to a cloud platform, and cross-border transfer requirements have to be checked against the current position rather than assumed from an older project. Confirm before the design is fixed which datasets can leave Malaysia, which cannot, and what the provider’s own data processing terms commit to.
Three questions settle residency for most estates. Which datasets carry a legal or contractual residency obligation? Which workloads need low latency to Malaysian users or systems? And which need to stay close to systems that are not moving at all?
Getting the Data There
Bandwidth is the constraint that most often moves a migration date, and it is arithmetic anyone can do in advance. Divide the volume to be moved by the throughput you can actually sustain, then double it for overheads and contention. If the answer is longer than your cutover window, the plan needs changing rather than compressing.
Three approaches, usually combined:
- Encrypted transfer over the internet for smaller volumes and for ongoing replication, subject to the bandwidth your sites genuinely have rather than the number on the contract.
- A dedicated connection to the cloud platform, provisioned through a carrier or an exchange. Lead times run to weeks, so this is ordered during phase 3 rather than during the first wave.
- Physical transfer devices for large datasets, where shipping encrypted media is faster than any available link. Plan the security and chain of custody for these the same way you would for backup media.
Whichever you use, replicate first and cut over second. Databases and file stores should be seeded and kept in sync ahead of the window, leaving only the final delta and the switch itself inside the outage.
What a Migration Actually Costs
The monthly platform bill is the part everyone models. Four other costs decide whether the business case holds.
1. Dual running. For the length of the migration you pay for both environments. This is the single largest cost overrun in migrations that slip, and it scales directly with delay.
2. Data transfer. Moving data in is generally cheap. Moving it out, or between regions and availability zones, is not. Architectures that chat across boundaries generate charges that are invisible until the invoice arrives.
3. Licensing. Some vendor licences do not transfer to cloud infrastructure on the same terms, and per-core models can behave differently on cloud instance types. Check entitlements during assessment, not during cutover.
4. People and tooling. Training, new monitoring and cost management tooling, and the operating model change. Teams that ran fixed capacity now have to manage consumption, which is a different discipline.
Against those, the savings are real but conditional: hardware refresh avoided, data centre space and power released, and capacity that scales down as well as up. The last one only materialises if someone is accountable for scaling it down.
Go-Live Gate: 12 Criteria Before Each Wave Cuts Over
Run this as a gate for every wave, not once for the programme. Any criterion unmet is a reason to move the date rather than to proceed and manage it.
- Workloads in this wave have a named business owner who has approved the cutover window
- Dependencies mapped, including systems that are not moving in this wave
- Landing zone controls in place: identity, network, logging, guardrails, tagging
- Data classification confirmed, and residency requirements satisfied by the target design
- Backup configured in the target environment and a restore tested there
- Recovery time and recovery point objectives defined for the target, and tested
- Performance tested at production volume, not at sample volume
- Integrations tested end to end, including any that cross back to on-premises systems
- Rollback plan documented, with the point of no return identified and agreed
- Cutover runbook rehearsed, with named people and times
- Monitoring, alerting and support arrangements live before the first user
- Cost baseline recorded, with tagging in place to attribute spend after go-live
Where Strateq Fits
Strateq has run enterprise infrastructure in Malaysia since 1983 and has been building cloud practice on top of that for over a decade, which is a useful combination when most of an estate is not moving all at once.
On platform depth, Strateq is an AWS Advanced Tier Partner and works across public, private, multi-cloud and sovereign cloud, so a workload-by-workload strategy does not have to be bent to fit a single platform relationship. That matters most for the retain and hybrid decisions in the table above, which are the ones a single-platform partner has the least incentive to recommend.
On residency, Strateq operates its own data centres in Malaysia, so workloads carrying an in-country obligation have a home that does not depend on a hyperscaler’s regional roadmap. On phase 6, the operating model after go-live, the same teams provide managed services for the estate once it lands.
Take the go-live gate into your next migration planning session, and talk to Strateq’s enterprise cloud team if you want the assessment phase run before you commit to a date.