A cloud migration rarely touches just one system — data protection, availability, internal responsibilities and existing contracts are usually tied up in it too. If you approach IT providers before settling these points internally, you'll get offers built on assumptions that later turn out wrong, with delays and add-ons to match. The following checklist summarizes the questions to answer before your first request.
What does the current state look like?
Which systems, applications and data should be migrated? Where do they run today — in-house, with a hosting provider, already partly in the cloud? The more precisely you can describe today's state, the more realistically a provider can estimate the effort.
What dependencies exist to other systems?
Hardly any system stands alone. Check in advance which other applications, databases or external services connect to the system being migrated — via interfaces, shared databases or authentication services. An incomplete list of dependencies is one of the most common reasons a migration stalls mid-implementation: a provider can only plan for what it already knows about. Even seemingly minor peripheral systems — such as a rarely used report or an interface to an external service provider — belong in this inventory too.
What is the target picture, and why?
Decide which target platform or strategy you're aiming for and why — cost savings, better scalability, resilience, or retiring your own hardware. A clear "why" helps providers propose the right technical solution instead of a generic one that misses the actual goal.
How is personal data handled?
Once personal data is involved, where it's processed and applicable data-protection requirements play a central role in choosing the target platform and provider. Clarify these questions internally with your data protection officer (if you have one — otherwise with whoever holds that responsibility in your company) before requesting offers. The concrete legal assessment belongs with that role, not in a general request.
What availability and downtime requirements apply?
How critical is the affected system to ongoing operations? What downtime is tolerable in the worst case, and what isn't? These answers strongly shape which target architecture and migration approach are even viable — and, with it, the price.
What rough migration strategy applies?
Two basic approaches are common in practice: lift-and-shift moves existing systems into the new environment largely unchanged — faster to implement, but often only partially uses the target platform's advantages. Refactoring adapts applications specifically for the new environment — more effort, but often with better long-term results for cost, scalability or maintainability. Which approach fits depends on the individual case; what matters is that you form a rough opinion on it in advance, so that offers using different approaches remain comparable at all.
| Approach | What happens | Typically suited to |
|---|---|---|
| Lift-and-shift | Existing systems are moved into the new environment largely unchanged | Time-critical migrations, stable legacy systems with little need for adaptation |
| Refactoring | Applications are specifically adapted for the new environment | Systems where scalability, cost or maintainability matter most in the long run |
Some projects combine both approaches: non-critical peripheral systems via lift-and-shift, core applications with targeted refactoring. You should also settle this in advance as a rough frame, rather than leaving it to the provider to guess the right approach.
What time window is available?
Are there maintenance windows where a migration can happen without disrupting operations? Are there seasonal periods unsuitable for migration, such as year-end closing or peak business times? These answers shape the realistic timeline considerably.
What internal resources and responsibilities exist?
Who is available internally for questions, approvals and testing during the migration? A migration planned without any internal time budget regularly leads to delays in practice, because urgently needed approvals or information are missing.
How will you know the migration succeeded?
Decide in advance which criteria define completion of the migration — for instance: is all data fully and correctly transferred? Do all interfaces still work as before? Are the agreed availability requirements met? Without such criteria, it stays unclear when a project is actually done, and disagreements over whether further fixes are needed become almost inevitable. A short test period after cutover, during which regular operations are observed under real conditions, also belongs in this consideration.
What fallback plan exists?
What happens if the migration doesn't go as planned or the result falls short of expectations? A fallback plan should clarify how long the previous environment keeps running in parallel, under what conditions you'd switch back, and who decides that. It's also worth having a rough exit strategy for the new environment itself: how would you get back out of it if needed, for instance in the event of a provider switch or a change of target platform? A provider who's never even asked about this point has, in practice, no reason to address it in the offer either.
What ongoing costs are realistic to plan for after the migration?
The migration itself is only part of the cost picture — at least as important are the ongoing operating costs of the target environment. Ask yourself in advance whether you have a rough idea of how usage, and therefore cost, might develop in the new environment, and whether these costs will be monitored regularly and assigned to an internal owner. An offer that only prices the migration itself, but says nothing about the foreseeable operating costs afterward, gives you only half the basis for a decision.
Carrying these questions into the request
The answers to the questions above don't just belong in internal notes — they belong in the scope description itself, the one you use to request offers. A provider who knows today's state, the target picture, the availability requirements and the available time window can calculate an offer that actually fits your undertaking, instead of one built on their own assumptions that only turn out to be wrong once the project is under way. The guide to writing a scope description covers in more depth how a complete scope description should be structured.
What clear answers achieve
The clearer your answers to these questions, the more precisely providers can align their approach, timeline and price with them. Conversely, open questions at this stage almost inevitably lead to offers built on different, unspoken assumptions — and are therefore neither realistic nor comparable with each other. Different providers fill the same gap in the request in different ways, and in the end you're no longer comparing the same service, just different assumptions about what was meant.
Careful internal preparation for a cloud migration isn't bureaucratic overhead — it's the foundation that lets the offers you receive actually form a solid basis for a decision. Anyone who takes the time upfront to clarify the current state, the target picture, data-protection questions, availability requirements, migration strategy, time window, internal responsibilities and fallback plan ends up with offers that are not only easier to compare, but also noticeably less likely to lead to unpleasant surprises once the project is under way.