Send a workload brief before you ask for a cloud migration price. Name the systems you want to move, what they connect to, and how long each can be unavailable. That gives a supplier something useful to assess. A request that only says "move us to the cloud" leaves the hardest parts unpriced.

You do not need to choose AWS, Azure, or Google Cloud before this first conversation. You do need to explain what must keep working. Use the questions below to prepare a short brief, even if some answers are still unknown.

List the work, not just the servers

For each application, record its owner, users, purpose, hosting location, database, storage, and busiest hours. Add the systems it calls, such as payment tools, identity providers, email services, and shared databases. Mark anything that must move together. Microsoft's workload assessment guidance recommends checking components and dependencies with the people who run them, because tools can miss undocumented connections.

Start with one business process, such as submitting an order or finding a client record. Trace it from the screen to the database and any outside service. This often finds more migration work than a server list does.

State the downtime and data limits

Write down who uses each system and what happens if it is unavailable. Name any fixed closing dates, busy periods, or maintenance windows. State how much recent data the business could afford to lose if a move fails. These are decisions for your business owner, not guesses for a supplier.

Flag sensitive records and any location or access rules that apply. Ask your legal or security owner to confirm the requirements. A cloud provider or developer cannot infer them from the application name. Microsoft's migration plan template includes data sensitivity, operating location, owners, downtime limits, and dependencies for each workload.

Ask for a cutover and rollback plan

A useful quote explains how the new environment will be tested before users move. It should name the final data copy, the traffic switch, the checks after the switch, and the person who can stop or reverse it. The exact method depends on your system and its downtime limit.

AWS cutover guidance describes backup, final data sync, routing changes, and validation. It also warns that new transactions after a switch can complicate rollback. Ask how your supplier will handle that case rather than accepting a blanket "no downtime" promise.

Compare the full operating cost

Ask each supplier to separate one-time discovery, migration, testing, and training from monthly cloud and support costs. Include backups, storage, data transfer, monitoring, and the staff time needed to run the system. The answer depends on your actual usage and target design, so a generic monthly figure is not a reliable quote.

Also ask who will own access, billing, alerts, updates, and incident response after launch. A move is incomplete if the application runs but no one knows who maintains it.

A short brief to copy into your quote request

  • Which applications and databases need to move, and who owns each one?
  • What other systems, accounts, or vendors does each application need?
  • When can the service be unavailable, and how much data loss is acceptable?
  • Which records need special access, retention, or location rules?
  • Who will approve the cutover, test the result, and run the system afterward?
  • Which costs must the proposal show separately, including monthly operations?

Mark missing answers as open questions. A good discovery step can resolve them before a fixed scope or price is agreed. CIT offers cloud migration services for teams that need this planning and delivery work. Send CIT your brief through the quote form to discuss the scope.