Who this is for
This checklist, Checklist: move a line-of-business app to the cloud, is for the people who own and run a business application, not for a generic server move. The app might handle billing, claims, scheduling, inventory, payroll, case management, or field service. It has users, integrations, reports, and a vendor who supports it. That mix is what makes the move different from lifting a virtual machine.
Founders and CTOs use it to set scope and decide who signs off. IT and operations leads use it to plan the work. Finance and business owners use it to protect the close period, the billing run, or the service window. If nobody can name the business owner, stop and find that person first.
The goal is a working app in the cloud with a known support path, tested rollback, and users who can do their jobs on Monday. A cheaper bill is not the point. Keeping the app supported and the business running is.
Before you begin
Pick one app and one release. Do not combine the move with an upgrade unless the vendor requires it. Two changes at once make it hard to tell what broke. Set a date range for discovery, a pilot window, and a cutover window, then write the success tests: login, core transaction, report, integration, and batch job.
Get the current state on paper. Ask for the architecture diagram, server list, app version, database version, middleware, file paths, scheduled jobs, and every external endpoint the app calls. Include the boring details: SMTP relay, print service, fax gateway, badge reader, payment terminal, SFTP drop, and spreadsheet upload. Those details break more cutovers than CPU does.
Open a support ticket with the app vendor and ask three questions in writing: which cloud topologies they support, which versions are in support, and what changes on their side for licensing or remote support. Save the answer. Check backup and restore now, and confirm you can restore the app and its data into a test environment. If you cannot restore today, that is the first project.
The checklist
Use this list in order, but do not treat it as a waterfall. Some items run in parallel. The point is to close gaps before users see the new environment.
The app layer is where most surprises live. A database can be copied. A server can be recreated. An app carries user identities, vendor rules, hard-coded IP addresses, and a report that only one person knows how to run.
Keep a decision log. Record what you chose, who approved it, and what would make you reverse it. That log is more useful than a long status deck.
- Name one application owner who can approve the cutover, the rollback, and any change to the business process.
- Get the vendor's supported cloud topology, version matrix, and licensing terms in writing before you design the target environment.
- Draw the full request path from client to DNS, load balancer, app server, middleware, database, file store, and external API.
- List every integration with its protocol, source IP, authentication method, and timeout behavior, then mark which side must change.
- Choose rehost, replatform, or replace, and write down why the other options are worse for this release.
- Move configuration and secrets out of server images into environment variables or a managed secret store, and record who can read them.
- Connect the app to the company identity provider through SAML or OIDC where supported, and document the break-glass local account.
- Test response time from each real office and from a home connection before you choose the cloud region.
- Build a data copy plan with row counts, file counts, delta sync, freeze window, and a named person who signs off on completeness.
- Set up centralized logs, health checks, and alerts for the app, middleware, and scheduled jobs before the pilot starts.
- Restore the app and its data from backup into the new environment, time the restore, and confirm the vendor supports that path.
- Pilot with a power user, an occasional user, and a business owner who checks the output, not just the login screen.
- Write the rollback trigger, the decision maker, the traffic switch steps, and how long the old environment stays warm.
- Schedule hypercare for the first close period or billing run, with named people on the business and technical sides.
What good looks like
A good move has no mystery dependencies. The vendor has confirmed the target in writing. The app owner can explain what a successful transaction looks like. Support can reach the new environment through a documented path, and the company does not depend on one admin's laptop.
Users see normal response times from their real locations. Single sign-on works, and the local fallback account is sealed and monitored. Logs show the app, middleware, and jobs in one place. A restore has been timed, not assumed. The cutover has a short freeze, a clear switch, and a rollback that someone has practiced.
Watch for warning signs: a vendor that says the app should work, an integration list with no owner, a test plan that only covers login, a cutover scheduled on a close day, or a rollback plan that says restore from backup without a time estimate. Those are reasons to slow down, not to push harder.
What to do next
Start with the inventory and the vendor call this week. You do not need a cloud account to do either. Turn the integration list into a table with owners. Mark each item as tested, changed, or accepted risk. Then pick the pilot group and book their time.
If the app is core to revenue or a regulated process, get an independent architecture review before you commit to a pattern. A short discovery can save a failed cutover. If you need help with the target design, the phased plan, and a fixed price for phase one, one option is the Cloudverg Discovery and roadmap sprint at $9,500 fixed price. It runs two weeks, starts within 10 business days, and the fee is credited to phase one if you start within 60 days. The documents are yours to keep.
Do not move the hardest app first. Pick one with a willing business owner, a cooperative vendor, and a rollback you can live with. Use that move to prove the pattern, the runbooks, and the support path. Then reuse what you learned on the next app, with a shorter checklist and fewer surprises.
Frequently asked questions
How long does it take to move a line-of-business app to the cloud?
There is no fixed timeline. A simple app with a cooperative vendor and few integrations can move in weeks, while an app with custom integrations, identity changes, and a close period can take months. Plan by phases: inventory, design, build, test, pilot, cutover, and hypercare. The vendor's support response time often sets the pace more than the cloud work does.
Can we lift and shift a line-of-business app?
Sometimes, but a lift and shift still needs app-level checks. Confirm the vendor supports the target, test latency from real user locations, move secrets out of images, and map every integration that uses a fixed IP. If those checks fail, replatforming or replacing the app may cost less than forcing the move.
What is the biggest risk in an app migration?
Hidden dependencies and weak vendor support cause more trouble than compute or storage. An integration nobody owns, a hard-coded IP allowlist, or a report tied to a local file path can stop the cutover. Test restore and rollback before the pilot, and give the business owner authority to delay.