Cloud migration: how to prepare business infrastructure for the move

Cloud migration should start not with choosing a server, but with checking business dependencies. Until the team knows which systems accept orders, where data is stored and who restores operations after a failure, moving simply relocates the risk. The practical outcome of preparation is an agreed system map, readiness criteria, a cutover plan and a clear operating budget.

For the owner of an online store, B2B portal or corporate web system, the main question is this: can the business process its operations during and after the transition? An available homepage does not prove that payments are confirmed, stock is updated and documents reach the ERP. These are the chains that need testing before launch.

Below is a preparation plan for infrastructure migration from owned hardware, rented servers or another cloud environment. It is not a guide to changing a CMS or migrating SEO URLs. The application can remain on the same platform while its network, storage, database, access controls and support arrangements change substantially.

1. Define the reason for moving and the project boundaries

Describe the problem migration needs to solve: difficult recovery, insufficient peak capacity, hardware reaching the end of support or cumbersome environment management. “Being in the cloud” is not a verifiable outcome. The ability to restore order processing within an agreed time or deploy a test environment using a documented procedure can, however, be demonstrated.

Record the baseline: normal and peak load, response times for critical operations, error frequency, data volume and actual costs. Choose a representative period covering your operating cycles. If promotions drive the store, observing only quiet days will not provide enough information for resource planning.

Define separately what is outside the first wave: redesign, CRM replacement, catalog restructuring or a complete application rewrite. Combining every change makes it harder to identify the cause of a failure. For older components, the approach in GOV.UK guidance on managing legacy technology is useful: assess the system’s risk and capabilities rather than declaring it unfit solely because of its age.

2. Map dependencies around business operations

An inventory must cover more than servers. Record applications, databases, file storage, message queues, search, caching, job schedulers, payment and logistics integrations. Each component needs an owner, purpose, environment, version, configuration source and recovery method. An unknown owner is a concrete scheduling and support risk.

Check connections in both directions

In a hypothetical online store, a customer places an order, the payment service sends confirmation, the CRM receives the inquiry, the ERP reserves stock and the delivery service returns a shipment number. This is a learning scenario, not a GL.ua case study. For each connection, record its address, protocol, authentication method, acceptable delay, retries and behavior when the neighboring system is unavailable.

Check callbacks too: an external service may contact an old IP address or allow requests only from the previous network. Daytime traffic will not reveal a monthly export or overnight reconciliation. Compare conversations with process owners against configuration, logs and network observations. An automated inventory helps, but does not explain a connection’s business importance on its own.

Group systems by shared risk

If an application frequently accesses a database, separating them across environments may change latency and data transfer costs. If several services share files, moving one separately requires a data consistency check. In Google Cloud’s workload assessment guidance, inventory and dependency discovery are part of migration preparation. The practical conclusion is to plan waves around connections, not the order of servers in a list.

3. Turn readiness into entry criteria

Readiness means being prepared to migrate, supported by evidence. Do not settle for “almost ready.” For each wave, define what has been checked, who accepts the result and which unresolved issue stops the transition. Criteria must cover technology, data, security, finances and the on-call team.

This table is a working template, not a universal certification standard. Add your own constraints. For example, a reporting-period close or promotion may be a poor time even for a technically ready wave. The business process owner must approve the change window and operating arrangements if some functions need temporary restrictions.

Component decisions may differ: move with little change, adapt to a managed service, rebuild a specific part, retain it in place or retire it. Do not automatically redesign everything for a new architecture. A pilot should test real uncertainty without putting the entire sales flow at risk.

4. Prepare a secure target environment

Before moving production data, define the structure of accounts, networks, environments and access. Separate testing from production. Document which components genuinely need public access and which should interact only within the agreed boundary. The responsible security engineer must review decisions about specific settings.

Create an inventory of service accounts and secrets: passwords, keys and integration tokens. Define their owners and how they are stored, rotated and revoked. Copying configuration from an old server without review can carry over excessive permissions and forgotten access. Check emergency access separately: it must be available to responsible people without becoming a shared everyday account.

Clarify who handles operating system, application and database updates, backups and incident response under the chosen service model. A cloud provider does not automatically assume all customer responsibilities. NIST SP 800-144 discusses public cloud security and privacy; it is a foundational document, not confirmation that a particular project meets current requirements.

For customer data, check where primary copies, backups and logs are stored, along with contract terms and contractor access. Do not draw legal conclusions from a provider’s region name alone. Constraints on personal or regulated data should be agreed with qualified specialists before selecting services. Then check that logs actually reach the intended destination and do not expose secrets.

5. Calculate total cost, not just virtual machines

Comparing the existing server bill with the price of a single cloud machine is not enough. The cost model must include compute, databases and storage, redundancy, data transfer, network components, logs, monitoring, licenses and support. Add test environments, temporary replication and the period when both old and new infrastructure are paid for simultaneously.

One-off work includes assessment, design, environment setup, data migration, integration adjustments, testing, rehearsal, cutover and documentation. Recurring costs cover resources and the team’s work after launch. Keep a separate line for uncertainty: an incomplete inventory, unclear licensing terms or the need to rework a component. This is more honest than a precise estimate without verified inputs.

Compare equivalent load scenarios

Build models for normal operations, peak periods and recovery after failure. Account for data growth and backup retention. Compare systems with similar availability and support requirements: a cheaper environment without redundancy is not an equivalent replacement for one with tested recovery.

To control costs, assign an owner to every resource, use clear project labels, agree on budget alerts and review bills regularly. Do not treat an alert as an automatic spending cap: check how budget tools behave for the selected service. After migration, compare forecasts with actual consumption and investigate deviations rather than simply increasing the budget.

6. Rehearse the complete business flow

Wave planning in the Microsoft Cloud Adoption Framework helps connect workload assessment with migration sequencing. For the business, it is important to add clear acceptance evidence. A pilot is not complete if the server runs but nobody has checked the operation’s outcome in an adjacent system.

1. Restore a data copy in the prepared environment and check completeness using the agreed method.
2. Follow the critical flow: sign-in, search, cart, order, test payment and transfer to CRM or ERP.
3. Check background jobs, repeated messages, error handling and reconnection after an interruption.
4. Reproduce representative load and compare latency and errors with baseline measurements.
5. Check alerts, backup recovery and the on-call instructions.
6. Rehearse cutover, recording step durations and stop conditions.

The test environment must not accidentally charge real money, message customers or create actual shipments. Agree in advance on integration test modes and handling of personal data. Confirming results requires more than the technical team: sales, warehouse and accounting owners must check their parts of the process.

If the web application changes alongside the move, separate infrastructure criteria from functional acceptance. For the web component, GL.ua’s online store and business website development can provide a reference point, but choosing a CMS alone does not resolve networking, redundancy or operations.

7. Agree on cutover, rollback and realistic timelines

The cutover plan must include the step sequence, executors, communication method and the person who decides whether to continue or stop. Describe when writes to the old system stop, how the final data changes move and when the new system becomes authoritative. Address caching of addresses and external IP allowlists separately.

Rollback after new writes needs a separate decision

Reversing a network route is easier than reconciling two databases that already contain different orders. The rollback plan must therefore explain what happens to new data: how it will be preserved, reconciled and transferred without duplicate processing. Replication and backups do not automatically replace this decision. If safe rollback is impossible after a particular step, explicitly mark that boundary and the forward recovery plan.

Before starting, agree on acceptable recovery time and acceptable data loss: RTO and RPO respectively. Business needs determine them, not a default value from a presentation. Use the rehearsal to test whether the architecture and procedure can meet those requirements. A documented indicator without a test remains a target, not a demonstrated capability.

Timelines depend on data volume and change rate, channel capacity, dependency count, component compatibility, access approvals and people’s availability. Separate windows are needed for rehearsal, acceptance and stabilization. Do not promise a completion date based only on server count: one complex integration can determine the entire critical path.

8. Finish migration with an operational handover

After cutover, check not only infrastructure health but also completed business operations: whether orders arrive, queues accumulate, stock matches and payments or messages are duplicated. Define owners and exit criteria for stabilization. Shut down the old environment only after agreed checks of data, backups and the need to return.

Hand over an up-to-date system map, role-based access, deployment and recovery procedures, support contacts and a schedule of regular checks. Remove unnecessary temporary access, inspect remaining resources and final bills. Otherwise, a technically completed move can leave two paid environments and a configuration nobody is ready to maintain.

Make readiness decisions on evidence: dependencies are known, data can be restored, critical flows work, security has been reviewed, costs are understood and the team knows how to act during a failure. If one piece of evidence is missing, adjust the wave rather than hide uncertainty behind a launch date.

Planning to move infrastructure for an online store or business portal? Discuss the project’s web component and integrations with GL.ua: start with a list of systems, critical operations and recovery requirements. This brief helps separate application work from infrastructure tasks and assign responsibility before changes begin.