A cloud migration is the process of moving applications, data, and workloads from on-premises servers or an existing platform into a cloud environment. For a Malaysian business, it works best when you treat it as a planned project rather than a switch you flip. The difference between a smooth migration and an expensive one almost always comes down to preparation.
This checklist is written for IT managers and business owners who are getting ready for a migration or a modernization project, and it walks through the readiness questions you should answer before anyone touches production. If you want the conceptual groundwork first, our explainer on cloud computing for Malaysian businesses covers how the cloud works and how to start; this article picks up where that one ends and gets practical.
Why does a pre-migration checklist matter?
A pre-migration checklist matters because most cloud projects fail on preparation, not on technology.
The cloud platforms themselves are mature and reliable, but a migration touches inventory, dependencies, network paths, identity, security, backup, and the day-to-day work of your users all at once.
When teams skip the assessment stage, they discover the surprises in production: an application that quietly depends on a local file share, a database that doubles in cost once it scales, or a user group in Johor that loses access on go-live day. A structured readiness pass surfaces those risks while they are still cheap to fix. It also gives you a baseline to measure against, so you can tell whether the migration actually improved performance, cost, and resilience.
How do you take inventory of what you have today?
You take inventory by building a complete, current list of every server, application, database, and service your business runs, along with who owns each one. You cannot migrate what you have not mapped.
Start with the obvious production systems, then capture the quiet ones: the accounting package on a single workstation, the legacy app a department maintains on its own, the scheduled scripts that nobody has touched in years. For each item, record its operating system, version, resource usage, business criticality, and the team or person responsible. This is also the moment to decide the disposition of each workload, often described as rehost (lift and shift), replatform (light changes), refactor (rework for cloud), retire, or retain on-premises.
A clear inventory keeps the project honest and prevents the classic mistake of migrating systems that should simply be switched off.
What is a workload assessment, and how do you do one?
A workload assessment is the analysis of each application’s performance profile, resource needs, and suitability for the cloud, and you do one by examining how each workload actually behaves rather than how you assume it behaves. Some workloads are excellent candidates for the public cloud because their demand is variable or seasonal; others are steady, latency-sensitive, or tied to specialized hardware and may belong on-premises or in a hybrid cloud arrangement.
A hybrid cloud keeps some systems in your own data center or a local facility while moving others to a provider, which is a common landing point for Malaysian businesses balancing modernization against data location and latency concerns. If you are weighing the options, our comparison of hybrid cloud vs public cloud explains the trade-offs.
The output of a good workload assessment is a ranked migration order, with low-risk workloads moving first to build confidence.
How do you map dependencies before you move anything?
You map dependencies by tracing every connection a workload relies on, because an application rarely lives alone. A single system may call a database, an authentication service, a payment gateway, a reporting tool, and a shared storage location, and moving it without those links intact is how outages happen.
Document the integrations, the network ports, the API calls, and the data flows between systems, then group tightly coupled applications so they move together rather than in pieces.
Dependency mapping also reveals hidden data location issues, such as a workload that pulls customer records from a system you intended to leave behind. Getting this right is one of the strongest predictors of a clean cutover, and it directly shapes the rollback plan you will build later.
What should you check about network and connectivity?
You should check that your network can carry the new traffic patterns the cloud introduces, because connectivity is the artery of any cloud deployment.
After migration, traffic that once stayed inside your building now travels to and from a cloud region, so bandwidth, latency, and reliability of your internet links become business-critical. Assess your current circuits, consider redundant connectivity, and look at where your chosen cloud region physically sits.
The arrival of local hyperscale infrastructure has changed this calculation for businesses across the Klang Valley, Selangor, and Penang: Amazon Web Services opened its Asia Pacific (Malaysia) Region with three availability zones in 2024, and Microsoft launched its own Malaysia Azure region with three availability zones in May 2025. Google has also announced investment in Malaysian cloud infrastructure.
Keeping workloads in a Malaysian region can reduce latency for local users and simplifies some data location questions, which matters for organizations serving customers across West Malaysia.
How do you handle identity and access during a migration?
You handle identity by deciding up front how users will sign in to cloud systems and who is allowed to do what, because identity becomes the new perimeter once your applications leave the building.
Plan whether you will extend your existing directory, synchronize it to the cloud, or consolidate accounts, and apply least-privilege access so people get only the permissions their roles require. Enable multi-factor authentication for administrative and remote access before go-live, not after. Review service accounts and shared logins, which tend to accumulate over the years and become a security weakness. A clean identity model also reduces user impact at cutover, because people keep familiar credentials instead of juggling a new set for every system.
What does cloud security readiness look like?
Cloud security readiness looks like a clear set of controls covering access, encryption, monitoring, and configuration, defined before migration rather than retrofitted afterward. The cloud operates on a shared responsibility model: the provider secures the underlying platform, but securing your data, identities, and configurations remains your job.
Plan encryption for data at rest and in transit, define your network controls and firewall rules, and set up logging so you can see what is happening across your environment. Misconfiguration, not provider failure, is the leading cause of cloud incidents, which is why a deliberate security baseline matters so much.
Our guide to cloud security practices goes deeper on the controls, and businesses that want hands-on support can bring in dedicated cybersecurity and ongoing system monitoring to watch the environment after go-live.
How do backup and data protection fit into the plan?
Backup and data protection fit in as a non-negotiable safety net you confirm is working before, during, and after the move.
A common and dangerous assumption is that moving to the cloud automatically protects your data; in reality, you still need a backup strategy that you own and test.
Decide what you back up, how often, how long you retain it, and where the copies live, then verify that you can actually restore from them. This is also your rollback foundation: if a migrated workload misbehaves, a recent, tested backup is what lets you return to a known-good state. Plan for disaster recovery alongside everyday backup. For a managed approach, our data protection and backup services cover retention, testing, and recovery.
What about data location and PDPA?
You need to know where your data will physically live and whether moving it crosses a border, because Malaysia’s Personal Data Protection Act sets rules for both. The PDPA was amended in recent years, and the revised cross-border transfer provisions under Section 129 came into force on 1 April 2025, replacing the old whitelist approach.
Under the current framework, transfers of personal data outside Malaysia generally rely on the destination having comparable protection, on documented mechanisms such as standard contractual clauses, or on a transfer impact assessment, which the regulator’s guidance indicates remains valid for up to three years. In practical terms, choosing a cloud region inside Malaysia keeps personal data local and sidesteps much of this complexity, while a region abroad means you should document your basis for the transfer. This is technical guidance for planning, not legal advice; for obligations specific to your business, confirm the details with a qualified advisor.
A scannable cloud migration readiness checklist
Use the questions below as a quick readiness pass; if you answer no to any of them, that item needs attention before you migrate. Walk through them with your team and treat each no as a task, not a blocker to ignore.
- Do you have a complete, current inventory of every server, application, and database, with a named owner for each?
- Have you assigned a disposition (rehost, replatform, refactor, retire, or retain) to every workload?
- Have you assessed each workload’s performance and cost profile, and ranked a migration order starting with low-risk systems?
- Have you mapped the dependencies, integrations, and data flows between systems so coupled workloads move together?
- Have you confirmed your network bandwidth, latency, and redundancy can support cloud traffic patterns?
- Have you chosen a cloud region and confirmed where your data will physically reside?
- Have you defined how users will sign in, applied least-privilege access, and enabled multi-factor authentication?
- Have you set a security baseline covering encryption, firewall rules, configuration, and logging?
- Do you have a backup that you own, with retention defined and restores actually tested?
- Have you documented a rollback plan for each workload in case something goes wrong at cutover?
- Have you confirmed your data location and cross-border position under the PDPA?
- Have you decided who supports the environment after go-live and how issues will be escalated?
How do you plan for user impact and rollback?
You plan for user impact by deciding in advance how people will keep working through the migration, and you plan for rollback by knowing exactly how to undo a move that goes wrong. Communicate timing, expected downtime, and any changes to how staff log in or access files, and schedule cutovers for low-traffic windows so a finance team in KL or a branch in Selangor is not caught mid-task.
For every workload, define the trigger that tells you to roll back, the steps to do it, and the tested backup or snapshot you will restore from. A migration without a rollback plan is a gamble; a migration with one is a controlled, reversible change. Pilot with a small group before a full cutover wherever possible, so real user feedback shapes the final move.
What is the right support model after go-live?
The right support model is one that keeps your cloud environment monitored, patched, optimized, and accountable after the migration ends, because go-live is the start of operations, not the finish line. Cloud cost can drift upward without attention, configurations can fall out of compliance, and performance needs tuning once real workloads run.
Decide whether your in-house team will own day-two operations, whether you will use managed cloud services, or whether a managed IT services partner will handle monitoring, security, and optimization for you. Many Malaysian businesses choose a hybrid of the two, keeping strategic control in-house while outsourcing the routine operational load.
Whatever you choose, settle it before go-live so there is no gap in ownership on day one.
Bringing the checklist together
A successful cloud migration is the sum of small, deliberate decisions made before the move: knowing what you have, understanding how it connects, protecting the data, planning for the people, and naming who keeps it running afterward. Work through the readiness questions honestly, fix the no answers, and you turn an intimidating project into a manageable sequence of steps. The reward is an environment that is more resilient, more flexible, and easier to scale.
If you would like an experienced team to run a cloud assessment, map your workloads, and plan a low-risk migration with you, Callnet Solution works with businesses across Malaysia to do exactly that. Reach out for a free, no-obligation consultation and we will help you turn this checklist into a clear, costed migration plan.
