An ageing server is a good reason to review your infrastructure. It is not, on its own, a complete reason to move every workload to Azure.
A useful migration plan explains what the business expects to improve, what must keep working, and how the new environment will be operated. The technical transfer is one part of that plan.
Define the outcome before the architecture
Choose measurable objectives. You might need to support another location, reduce dependence on a single office, replace unsupported infrastructure, or improve recovery after a failure.
Write down the current problem and the target outcome. “Improve reliability” needs a definition: which service, which business hours, and which failure scenarios?
Microsoft’s Cloud Adoption Framework connects strategy and planning with readiness, adoption, governance, security, and ongoing management. Use that sequence to organise the work. Explore the framework.
Map the dependencies people forget
A server inventory tells you what exists. A dependency map explains what will break if something moves.
Interview the people who use the workload and document:
- Applications, databases, and supported versions.
- Identity, DNS, certificates, and service accounts.
- File shares, scheduled jobs, and integrations.
- Printers, scanners, and local equipment.
- Network paths, latency sensitivity, and remote access.
- Owners, support vendors, and maintenance windows.
Pay attention to integrations that run monthly or quarterly. A migration tested on an ordinary Tuesday can still fail at month-end.
Decide what each workload deserves
Some workloads may be suitable for migration with limited changes. Others may benefit from a managed service, replacement with a SaaS product, retirement, or continued on-premises operation.
Evaluate compatibility, vendor support, data requirements, and operating effort. A hybrid arrangement can be a deliberate design choice when local dependencies or performance needs justify it.
Ask what the business gains from moving each workload now. Prioritisation should follow that answer.
Build a cost model that includes operations
Estimate more than virtual machine compute. Include storage, backups, networking, data transfer, monitoring, security, support, and relevant software licensing.
Also budget for migration work, testing, temporary overlap with the current environment, and training. Model normal demand and a realistic peak rather than presenting one optimistic monthly figure.
Document assumptions so the estimate can be challenged. What happens if storage grows faster than expected, or an application needs a larger configuration after testing?
Design recovery and administration before cutover
Agree how much data loss and downtime the business can tolerate. Identify backup coverage, restoration steps, emergency access, and who can authorise recovery.
Assign owners for costs, security policies, updates, and monitoring. Define who receives alerts and what they are expected to do. An environment without operating ownership can become harder to manage after migration.
Pilot, rehearse, and make the go/no-go explicit
Start with a manageable workload that teaches you something useful. Test the application’s business functions, access, performance, monitoring, and recovery.
A cutover checklist should identify the change window, data synchronisation approach, acceptance criteria, rollback triggers, and the person making the final decision. If users enter data after the move, the rollback plan must account for those changes; switching a server back on is not enough.
After migration, confirm the outcome before decommissioning old dependencies. Track actual cost and performance against the original assumptions.
Begin with one workload
Choose a candidate application and complete the dependency, cost, and recovery review before expanding the programme. That gives leadership something concrete to evaluate.
Cover illustration: Growtika / Unsplash.
Guava welcomes conversations about Microsoft cloud planning and the products that support it. Explore Guava’s product collection, or bring your workload requirements to a discussion about the next step.
