Which Workload Should Move First?

Migrating IT infrastructure to the public cloud is a daunting prospect containing unique challenges to each organisation. Disruption, cost implications, training requirements, uptime SLAs, and managing security are all among considerations that can’t be overlooked. How do we break this process down into a logical linear process that mitigates all the potential disruptions?

 

Before diving into prioritisation, we need to grasp exactly what cloud migration entails. At its core it involves transferring data, applications, infrastructure and IT processes from on premises into the cloud. This is a web of physical infrastructure, licensing, data and processes, so undertaking such a journey shouldn’t be taken lightly, and a consultative approach to the project with appropriate budgetary constraints and business ROI objectives, is crucial. In this blog we’ll cover how Cybit assess workloads, mitigate risk and lay out a migration process that falls in line with industry standard procedures.

 

Prioritising workloads

 

“Cloud migration” is a collective term for a range of resources, hardware, processes, applications and data. The goal here isn’t just to migrate the workloads but to optimise your environment as well – there’s no use in going down this path if the environment you move to is less secure, more expensive with worse.

 

•Complexity and Dependencies:
oOpt for workloads with minimal interdependencies. Applications that are self-contained or have few ties to other systems are easier to lift and shift without causing ripple effects.
•Business Criticality:
oAvoid starting with core, revenue-generating applications. Instead, target non-production environments where downtime has limited impact.
•Cloud Compatibility:
oChoose workloads that align well with cloud-native features, such as those running on supported operating systems or requiring scalable resources. Certain legacy applications may not work with PaaS solutions such as Azure SQL.
•Cost and ROI:
oPrioritise those offering quick cost reductions, like variable workloads that benefit from pay-as-you-go models or indeed 24/7 workloads where reserved instances can provide discounts. Certain licenced instances could be running out of support and incentives from the likes of Microsoft could allow you to continue with extended support updates when running in Azure.
•Security and Compliance: Ensure early movers comply with regulations without needing extensive rework.

 

It’s important to work with your migration partner to implement a landing zone (using the likes of ARM for Azure or CloudFormation for AWS) to create a secure, scalable and standardised foundation to build your cloud resources. This will ensure security/compliance and will facilitate faster scaling much more quickly and have these configurations built in from the get go.

 

Recommended Workloads to Migrate First

 

At Cybit, we the Cloud Adoption Framework directed for providers such as AWS or Azure to ensure that the migration process is structured, linear and follows best adoption practices. That said, every organisation will be different and will have different requirements, but we see typical environments that can move much more easily:

 

1.Development and Testing Environments

 

Dev/test workloads are often isolated, non-critical, and resource-intensive on-premises. Migrating them first allows teams to experiment with cloud tools, optimise configurations, and identify issues early. They also benefit from cloud elasticity, enabling on-demand scaling without long-term commitments.

 

2.Stateless Applications

 

Applications without persistent data storage, such as web front-ends or APIs, are prime candidates. They can be easily replicated and scaled in the cloud, offering quick wins in performance and availability. This approach minimises data transfer complexities and reduces migration time.

 

3.Backup and Archival Data

 

Cold storage or infrequently accessed data is low-risk to move. Cloud services like AWS S3 or Azure Blob Storage provide cost-effective, secure options with built-in redundancy. Starting here builds familiarity with data migration tools and processes. Note that cooler storage tiers will come with higher transaction costs but a thorough assessment will identify the data to tier approximately.

 

4.Non-Production Workloads

 

Staging servers, internal tools, or employee collaboration platforms (e.g., email archives) have lower stakes. Migrating these first tests the waters for security configurations and integration with existing systems.

 

5.High-Cost, Low-Utilisation Servers

 

Underutilised on-premises servers draining resources can be prioritised for migration to realise immediate savings through cloud optimisation.
Avoid starting with database-heavy or tightly coupled legacy systems, as they often require refactoring and could delay the project.

 

Each organisation will be different, and any migration should be properly assessed using the relevant tooling to monitor your environment for an extended period of time. Rushing into migration without assessment can lead to hidden dependencies surfacing, so any migration should be simulated in a sandbox environment before pulling the trigger.

 

Conclusion

 

By starting with low complexity workloads like test/dev environments or stateless applications you can see early successes that pave the way for a more comprehensive transformation. Working through a phased and consultative migration with a MSP like Cybit will enable you to prioritise the workloads securely and appropriately in line with industry best practices to ensure a cloud migration is as successful as possible.