VMware to AWS Migration Around the Business Service

Imagine a distributor opening for business after a weekend migration. Employees can sign in, the application servers respond, and the database is available. Yet an order placed online never reaches the warehouse. A connection to an older dispatch system was omitted from the move. Every migrated machine can appear healthy while the order remains unfulfilled.

That hypothetical situation explains why a VMware to AWS migration should be planned around business services. Infrastructure inventory identifies what exists. A service map explains what must continue working together. For technology leaders, the useful starting question is which transactions the organization must protect, who can confirm their correctness, and what changes when their supporting infrastructure moves.

This approach also makes architecture discussions more concrete. The target might retain VMware, replace its virtualization layer with native AWS compute, or move selected components into managed services. Each choice needs a delivery plan that covers the whole transaction, including systems that remain outside AWS.

Define the service that must survive the move

Choose a business process and follow it from its first request to its final record. For the distributor, that could mean accepting an order, reserving stock, sending dispatch instructions, and creating an invoice. Record the application components, data stores, external connections, scheduled jobs, and people involved. Include rejected requests and delayed messages alongside the successful path.

Give every dependency an owner and a test. A warehouse interface might require a confirmed message receipt; an invoicing process might require matching ledger entries. These checks turn a broad requirement such as keeping operations running into observable acceptance criteria. They also reveal when moving servers separately would leave an awkward temporary connection between tightly coupled components.

Bring business owners into this work before assigning migration dates. A platform team can measure availability, but finance or operations may identify a failure that infrastructure monitoring misses. Their approval should refer to named tests and recorded results, giving the migration team a clear basis for proceeding or waiting.

Compare the operating models your team can support

Native Amazon EC2 is one destination for applications that can continue running on servers. AWS Transform MGN provides server replication and conversion for launch on AWS. Rehosting removes the VMware layer from those workloads, while responsibility for their operating systems and applications still needs an assigned owner.

Teams that need VMware continuity should assess Amazon Elastic VMware Service, or Amazon EVS. It runs VMware Cloud Foundation on EC2 bare metal infrastructure inside an Amazon VPC. Compare its licensing requirements, capacity, network design, and operational responsibilities with the native EC2 option. Familiar administrative tools do not make the two destinations commercially equivalent.

A third approach changes selected application components, such as adopting Amazon RDS for a compatible database. That decision introduces separate questions about database behavior and application changes. Treat it as additional engineering scope. Info Services' AWS capabilities provide a commercial starting point for discussing the wider architecture rather than treating every component as a server copy.

Price the transition as well as the destination

Compare costs across a common planning period. Include the AWS environment, software entitlements, connectivity, implementation work, retained infrastructure, and support. Temporary duplication matters: the source may need to remain available while the target is tested and accepted. A proposal that counts only the future production environment can conceal a substantial part of the transition budget.

Keep purchasing assumptions explicit. AWS ended resale of VMware Cloud on AWS on April 30, 2024. Existing customers should confirm their arrangements with Broadcom or an authorized reseller. Amazon EVS is a separate offering; its pricing information describes using eligible VMware Cloud Foundation licenses purchased through Broadcom or qualified resellers.

Ask for a workload comparison with the same availability requirements and operating coverage on each side. A cheaper estimate has little value if it excludes recovery capacity or shifts maintenance work onto an unprepared internal team. Record unresolved contractual questions before approving the business case, and obtain the appropriate licensing advice.

Rehearse the difficult parts before choosing a weekend

AWS Transform supports application grouping, migration planning, network translation, and server rehosting. Use those capabilities to prepare candidate waves, then review the proposed groups against the service maps. The application owner should be able to explain how a complete business process will operate during each intermediate state.

Select replication methods against the actual source configuration. MGN's agentless option uses snapshots through a vCenter client, whereas agent based replication has a different operating pattern. Review current prerequisites and limitations before committing a workload. During rehearsal, measure whether replication catches up under representative write activity and whether the source remains usable.

Run tests in an environment that prevents accidental business actions. Copies of scheduled jobs, integrations, or notification services can send duplicate instructions if they retain production access. Exercise deliberate failures as well: an unavailable identity service, an expired certificate, or a delayed interface response can expose assumptions that an ordinary login test will never reveal.

Use the pilot to test the delivery method

Choose a pilot that includes a meaningful dependency without exposing the business to an unacceptable interruption. An isolated utility server might be easy to move, but it will teach little about coordinating an application and its database. The pilot should answer a specific question that affects later waves, such as whether an external interface can tolerate the proposed network path.

Keep a short issue record during rehearsal. For each failure, identify the observed symptom, supporting evidence, corrective action, and retest result. Avoid closing an issue merely because it disappeared on the next attempt. Intermittent authentication or message delivery problems need an explanation before the procedure becomes the pattern for additional applications.

Review the pilot with the people who will perform subsequent moves. They should be able to repeat the instructions without depending on the original engineer's memory. If the procedure requires undocumented judgment, update it and rehearse again. The practical output is a repeatable process with known limitations, rather than a presentation declaring the pilot successful.

Decide what happens when the target accepts new writes

Cutover changes which system the business trusts. Name the person who can stop writes, authorize traffic changes, and accept the target. Set acceptance conditions before the migration window begins. Include data checks and representative transactions, with an agreed response if one passes while another fails. The decision should not depend on whoever speaks most confidently during the call.

Pay particular attention to transactions created after traffic moves. If the AWS application accepts an order, switching customers back to the old environment may strand that order on the target. The recovery plan must explain whether writes can be reconciled, replayed, or otherwise accounted for. A routing reversal alone does not resolve conflicting records.

Rehearse the decision itself, including the point beyond which the recovery approach changes. Record elapsed time for final synchronization, traffic changes, and application checks separately. This helps the business understand the outage window without confusing it with the entire migration program. No replication method removes the need to establish an application specific downtime estimate.

Read client evidence at the level it actually supports

The public Info Services IoT migration case study describes an agricultural software platform moving from a VMware based, three tier environment to an AWS architecture. The page names database services including Amazon RDS and Amazon DynamoDB, describes analytics components, and identifies Amazon S3 as a storage destination. Its scope includes application work beyond relocating virtual machines.

Those details help buyers understand the type of architecture involved. The page does not provide a measured cutover outage, a delivery duration, or a quantified result tied to a stated baseline. It also does not identify the migration tool. Buyers evaluating comparable work should request those records separately instead of treating a service list as proof of delivery performance.

A relevant reference discussion should follow the same transaction through the source design, migration procedure, and accepted target. Ask what failed during rehearsal and what changed afterward. That explanation often reveals more about delivery discipline than an isolated outcome number, especially when two projects involve different application changes.

Hand over the service before retiring the source

The first production week deserves its own plan. Assign responsibility for failed jobs, access requests, database maintenance, backup recovery, and unexpected spending. Test that the support team can find the right logs and reach the right application owner. A handover is incomplete when routine incidents still depend on the migration engineers remembering how everything was configured.

Choose retirement conditions for each source component. Confirm that delayed integrations, periodic reports, and recovery procedures have been exercised before removing the systems they previously used. Track any temporary connection with an owner and an end condition. Otherwise, a supposedly finished migration can leave both environments necessary for ordinary business operations.

Capture unresolved exceptions in the operating handover, including their business effect and the person accepting them. A workaround that is tolerable during rehearsal may be inappropriate for routine production. Review each exception before the source environment becomes unavailable and the remaining recovery choices become more expensive. This record should remain available to whoever supports the service afterward.

Start with a migration assessment built around your transactions

A workable plan connects architecture choices to business acceptance and ongoing ownership. Begin with one representative service, document its dependencies, and test the proposed migration approach before committing the wider estate. Request a VMware migration assessment from Info Services to discuss the source environment, destination options, and evidence your team needs for an informed decision.