Lift-and-shift assumptions for a mixed workload migration
A regional logistics company operates 18 physical servers across two sites: 6 web/API servers, 4 batch processing servers, 3 internal admin servers, 2 database servers, and 3 legacy file servers. It stores 6 TB of block data, 45 TB of object data such as scanned delivery receipts and photos, and 80 TB of archive data retained for seven years under a compliance policy. The CIO wants to move everything to NIFCLOUD within six months and has asked the team to treat NIFCLOUD as a drop-in replacement for the current VMware environment. Finance wants monthly costs to fall by 20%, but the archive is rarely read: about 2% of objects per year. The network team is worried about the internal admin servers, which must remain reachable only from the office VPN, and the database servers, which have a 15 ms latency dependency on the batch tier. No service mapping has been done yet.
1. Map each workload category to the most appropriate NIFCLOUD service category and explain the deciding factor for each mapping.
Read the worked answer
Map by access pattern, latency, and retention rather than by physical server count.
- Web/API servers: NIFCLOUD virtual servers in a private network. The application is stateless, so horizontal scaling and load balancing are feasible; no special storage semantics are required.
- Batch servers: Virtual servers, because the workload needs scheduled compute and local processing. Keep them in the same private network as the data they read, but do not assume they need the same instance size as the web tier.
- Database servers: Virtual servers with block storage. The 15 ms dependency on the batch tier and transactional I/O make low-latency block devices the deciding factor; object storage is unsuitable for database files.
- Legacy file servers: First check whether the application needs a mounted file system. If it only reads and writes files over HTTP or an API, object storage is a better fit. If it needs SMB/NFS semantics, keep block storage or re-platform the application.
- 45 TB receipts and photos: Object storage, because the data is accessed over HTTP, benefits from lifecycle rules, and does not need a block device.
- 80 TB archive: Archive storage. The deciding factors are the low retrieval rate (about 2% per year) and the seven-year retention requirement, not raw capacity.
- Admin servers: Virtual servers placed in a private network with VPN-only reachability. Do not expose them through the public load balancer just because other servers are public.
The key exam judgement is that a server is not automatically a one-to-one virtual server. Storage choice follows the application's I/O model, not the current hardware inventory.
2. Identify two assumptions in the CIO's plan that must be validated before migration and describe a concrete test for each.
Read the worked answer
Assumption 1: NIFCLOUD is a drop-in VMware replacement. Virtual server images, networking, and high-availability behavior may differ from the current VMware environment. A concrete test is to migrate two low-risk web/API servers first, run the same load profile for one week, and compare latency, boot behavior, image compatibility, and private-network reachability. Include a failure test: stop one server and confirm the load balancer removes it and the remaining server absorbs the traffic.
Assumption 2: Monthly cost will fall by 20%. The current cost baseline is not the same as a NIFCLOUD run rate. Archive retrieval, object storage requests, VPN bandwidth, load balancer hours, and operational labor can change the result. Build a cost model with three scenarios: 45 TB of object data with current request patterns, 80 TB archive with 2% annual retrieval, and a 20% buffer for data transfer. Then compare against the current monthly run rate, not against the purchase price of hardware. If the 20% target depends on moving databases to smaller instances, benchmark the database under batch load before committing.
Both tests are designed to fail cheaply. Discovering image incompatibility or a hidden egress cost after all 18 servers are migrated is much more expensive than a two-server pilot.
3. Recommend a migration order and justify it in terms of risk and dependency.
Read the worked answer
A defensible order is:
- Admin servers and VPN connectivity first. They are small, internal-only, and validate the private network, routing, and VPN path that later workloads depend on. Success here proves that the most constrained access path works.
- Web/API servers next. They are stateless, so rollback is simple: keep the old environment running and shift load balancer traffic gradually. This also tests load balancing and image deployment under real traffic.
- Batch servers after the web tier is stable. Batch has a latency dependency on the database, so migrate it only after the database network path and storage performance are understood. Run batch and web in parallel during a controlled cutover.
- Legacy file servers after deciding on re-platforming. If they move to object storage, the application must be tested against the new access method; that is an application change, not a pure migration.
- Databases last, or with a replication-based cutover. They carry the highest dependency and rollback risk. Use a replica or a maintenance-window cutover, and keep the old database available until batch and web have passed acceptance tests.
- Archive data in parallel, not as a blocker. Archive migration can run in the background because it is rarely read, but verify retrieval time and legal-hold handling before deleting the source.
The order moves from low-dependency, low-risk workloads to high-dependency, high-risk workloads, while using each stage to validate an assumption needed by the next.