A cloud project should begin with a business question: what needs to work differently? Moving a workload is a technical activity, but deciding why to move it requires a broader conversation.
This checklist is a planning aid, not a migration procedure. Architecture, security, cost, and implementation decisions need a review of your actual environment.
State the reason for the change
Write down the problem in business terms. Is it difficult to support a growing team? Is an existing environment approaching replacement? Are releases too dependent on manual work? Avoid assuming that a move alone will resolve an unclear problem.
Make an inventory
List the applications, data, integrations, and people involved. Record who owns each system and which other systems depend on it. Include the work that happens outside formal tools, such as spreadsheet exports and manually transferred files.
An inventory does not need to be perfect on day one. Mark unknowns explicitly so they become investigation tasks rather than hidden assumptions.
Clarify responsibilities
Discuss who will manage accounts, access, updates, incidents, and supplier relationships. Agree what your internal team owns and where outside support may be needed. Do not leave operational ownership until the end of the project.
Ask how costs will be reviewed
Identify the spending categories to investigate, including migration work, subscriptions, operation, and ongoing support. Ask who will review costs and how changes in usage will be assessed. A planning conversation should not promise savings without evidence from your workload.
Plan the transition conversation
Identify business periods when disruption would be particularly difficult. Ask about testing, recovery planning, access, and acceptance criteria. The detailed transition plan should be developed with the people responsible for the affected systems.
Agree the next investigation
Finish with a short list of what is known, what needs assessment, and who can provide the missing information. This makes it easier to define a realistic project scope before committing to a platform or timetable.
Explore a discovery conversation for questions to guide an initial discussion.