Cloud Consulting for Companies

Cloud Consulting: Planning a Cloud Transformation Without Handing the Costs Out of Your Hands

Cloud consulting settles which part of an application landscape belongs in a cloud, in which order it gets there, and who owns the running consumption afterwards. It rarely becomes urgent out of technical enthusiasm. It becomes urgent because a hardware generation is running out, a data centre lease is ending, an application no longer carries its peak loads — or because the monthly invoice of a cloud transformation that has already started grows faster than anyone can explain it. What that calls for is less a set of tools than a dependable application inventory, a target architecture with rules for network, identities and data residency, a migration cut into waves, and cost stewardship that runs along from day one. That is the working ground of cloud consulting.

Talk Through Your Cloud Project See the Areas of Work

Operations team watching a cloud environment across several screens in the control room

Leading companies trust our network

Where the Money Moves

What Cloud Consulting Delivers — and What It Cannot Decide for You

Two consultants going through a company's application landscape ahead of a cloud migration

Cloud consulting — sold in the market under labels such as cloud strategy consulting, cloud migration consulting or cloud computing advisory — answers which part of your own IT is better placed in someone else’s data centre, and what that changes about architecture, operations and accountability. Picking a provider is not its subject. The real difference to a classical data centre sits somewhere else, and it decides where a cloud consultancy can move anything at all.

The cloud moves money out of procurement and into daily decisions. In your own data centre the amount falls due once, at purchase, and then stands for years; a badly used machine shows up in depreciation, not at the end of the month. In a cloud environment almost every technical decision creates a recurring line item: a database sized too generously, a forgotten test cluster, a data path across a regional border. The total is not fixed at the start — it is created anew every day, where the work happens.

That is what determines where advice has leverage. It has leverage before the move, when the cut through the application landscape is drawn: which application travels unchanged, which is rebuilt first, which is retired, which deliberately stays. It has leverage in the rules that cap consumption before it arises — network segmentation, identities, environment separation, retention duties. And it has leverage wherever one person reads the invoice and the architecture together. Without that third place, every cost analysis stays a snapshot.

Where projects reliably run off course. An unchanged lift-and-shift carries a grown landscape, including its idle capacity, into a model that bills exactly that idle capacity every month. It is still often the right first wave, because it releases the site contract — but only with an agreed date on which the rework happens. Without that date the interim answer becomes a permanent one, on a rental tariff.

What cloud consulting does not deliver. It substitutes neither a platform provider nor a managed service provider; the environments themselves are run by you or by a partner you commission. It does not take the trade-off between speed and lock-in off your desk either — how tightly you tie yourself to one provider’s services is a commercial decision, not a technical one. And it does not replace a legal opinion: whether a particular data category may sit in a particular environment is settled case by case by data protection and legal. Anyone looking for the redesign of the surrounding processes will find it in digital transformation consulting.

Starting Situations

When Outside Help Gets a Cloud Project Off the Spot

Not every cloud project needs help from outside. Where the application landscape is manageable, where an environment has already been built cleanly in-house and where somebody has the time to do it a second time, the job is quicker and less expensive done from the inside. In the situations below the arithmetic usually comes out the other way — not because knowledge of your own IT is missing, but because routine with this particular kind of move is: a company relocates its core systems once, our network accompanies such projects continuously.

1. A Deadline Forces the Decision

Hardware at the end of its life cycle, a site contract running out, an announced end of support.
The date is fixed, the assessment of the applications is not — and without that assessment the move only extends what already exists.

2. The Move Is Running, the Invoice No Longer Explains Itself

Consumption climbs without anyone being able to attribute it to an application, a team or a decision.
Without attribution the cuts are made across the board — and they usually hit the wrong thing.

3. A Move of This Size Has Never Come Up In-House

Data migration, permission model, network connectivity and the exceptions that appear on no requirements list.
Mistakes in those places only surface in regular operations, and then they are expensive.

4. Every Unit Has Booked Its Own Environment

Several accounts, several providers, several payment routes — without shared rules.
Consolidating means first clarifying inventory and ownership, and only then touching technology.

5. Somebody Asks for Evidence

A regulator, a parent company or a major client asks about storage location, access routes and exit capability.
That evidence can rarely be produced after the fact; it comes out of architecture and documentation.

6. Operations Are Meant to Move From Project to Line

The environment stands, but on-call duty, change process and cost ownership are unsettled.
Without that step the project team stays in operations — permanently, and on project terms.

Does one of these points describe where you stand today? Fifteen minutes on the phone puts the picture in order: which applications earn an assessment first, which wave should open the sequence — and whether an external pair of hands is warranted here at all.

Set the Cloud Course

Areas of Work

From Cloud Strategy Consulting to the Cost Loop: The Areas of Work

Some engagements cover one of these areas, others several at once; what governs it is the stage the work has reached. In most cases the opening move is an assessment and a target state, with architecture, cost stewardship and operations arriving in whatever order the situation dictates. The list is a selection; the category page opens onto the specialisations that are not named here.

Cloud Strategy and Target State

Cloud strategy consulting answers where each workload belongs — public cloud, private environment or your own data centre — application by application instead of in one sweep. It includes an application inventory with dependencies and a sequence that still holds when the budget is trimmed.

Migration Planning and Wave Design

This is the core of cloud migration consulting, and the cut decides how the move runs: which applications travel together because they share data, which can be separated, where the way back lies. Every wave gets a scope, an acceptance criterion and a stopping point — so a problem costs one wave and not the programme.

Cloud Architecture and Landing Zone

The ground order of an environment before the first application moves in: account structure, network segmentation, identities and permissions, separation of test and production, logging, retention and recovery. Set up vendor-neutrally: we sell neither licences nor managed services.

Cloud Cost Stewardship and FinOps

Making consumption visible, attributable and turning it into a decision: tagging of resources, allocation to applications and teams, detection of idle environments and a monthly control loop with a named owner.

Operations, Automation and Platform Teams

How an environment is run after the move: infrastructure as code instead of click paths, monitoring and on-call duty, change process, reusable building blocks for the business units. The aim is a team that enables self-service instead of becoming the next queue.

Cloud Security and Sovereignty

Access rights, encryption, logging and key management are decided inside the project, and so are storage location, access routes and exit capability. We open the subject here; the depth belongs to a security mandate of its own.

Which of these areas needs to take hold first in your organisation is a question a short conversation can settle. Sketch the situation as it stands; the answer comes back as a judgement, not as slideware.

Talk Through Your Cloud Project

Engagement Formats

Four Formats in Which Cloud Consulting Gets Commissioned

What decides the outcome is often not depth of expertise but shape: how much capacity, with which mandate, over which period. Our network covers four shapes, and switching between them mid-course is the normal case. The same ground rules hold across all four: somebody inside the company owns the topic by name, the objectives exist in writing before anyone starts, and the point at which the mandate ends is fixed at the outset.

Clarify the Engagement

Stocktaking

Assess the Application Landscape

One experienced person records applications, dependencies, data paths and today's operating costs and delivers a reasoned recommendation per application. Sensible where the work happens internally and only the comparative experience is missing.

Architecture Mandate

Own the Target Architecture

One person carries the ground order of the environment and the rules by which everything is built later. Customary before the first productive application moves in, and always where several teams are meant to build in parallel.

Delivery Support

Ride the Waves With You

Outside specialists sit in the same team as your own staff, with the technical lead staying internal. This is the shape most data centre exits take. Because the work is done jointly, the learning does not leave with the contract.

Cost Stewardship

Steer Consumption for Good

A small, recurring involvement after the move: a monthly look at consumption and pricing models, clearing out idle environments. This shape is the one commissioned too late most often.

Industry Practice

Cloud by Industry: What Puts a Limit on the Move

The route into the cloud follows the same mechanics everywhere, but the limits sit in different places. In manufacturing the shop-floor connection caps how much can move at all; in retail the seasonal peak dictates when a move must not happen; in banking and insurance supervisory law sets the conditions for outsourcing and for exit; in public administration procurement routes and storage location decide. Whoever meets these particularities only during delivery pays for them in weeks.

Availability is therefore the wrong first filter. We staff from lived sector practice: people who have seen the system landscapes that are common there, who know how the audits are run, and who can name the point at which a comparable move got stuck. The network behind that spans 25 functional areas and upwards of 300 role profiles. The industries below are the ones we work in regularly — every tile says what decides the case there and how progress becomes visible.

Project Types

Cloud Projects That Get Commissioned Regularly — and the Number They Are Measured By

Look at what companies really put out to tender inside a cloud transformation and four recurring types emerge. Each one starts from its own situation, each one has a running order that experience keeps confirming, and each one is judged on a single agreed figure — written down at the outset and read off during the work, never guessed afterwards.

Retire a Data Centre

Starting position: own hardware at the end of its life cycle or a site contract running out, plus a fixed date. What has proven itself: assess first and switch a part off on purpose, then cut the waves, then move — each wave with a way back. The target number is the count of applications that have left the site by the cut-off date.

Get Costs Under Control After the Move

Starting position: the environment runs, the invoice grows, nobody can attribute it to a decision. The route runs over tagging and allocation, then over switching off what is idle, and only then over pricing models. The target number is cost per application or per transaction, not the total.

Retrofit the Ground Order

Starting position: accounts and environments grown over years without shared rules, often across several providers. First take inventory and assign ownership, then describe a target structure, then migrate step by step. The target number is the share of environments that meet the rules for network, permissions and logging.

Operating Model and Handover to the Line

Starting position: the project ends, operations are unsettled — on-call duty, change process, cost ownership, provisioning of new environments. First describe roles and approvals, then automate what recurs, then hand over. The target number is the share of requests the business units can serve themselves.

How a Cloud Transformation Is Cut Into Migration Waves and Run

How long each stage takes, and how wide it is, follows from the size of the estate; the order in which the stages come does not move. Record, decide, lay the ground order, relocate wave by wave, hand over. Nothing on that list is skipped. A stage is compressed only where solid earlier work already answers what it would have asked.

Step 1: recording the application landscape ahead of the cloud migration

1. Record the Applications

Applications, dependencies, data paths, licence ties and today's operating costs are captured — from what runs, not from the documentation.

Conversations with the business units and with operations surface the exceptions that appear on no system list.

The result is a reasoned recommendation per application: relocate, rebuild, retire or deliberately leave standing.

Step 2: target state and sequence of the cloud transformation are being set

2. Fix the Target State and the Sequence

For each application it is decided where it belongs and how tightly it may bind itself to one provider's services.

The order follows dependencies and risk, not visibility; deferred applications are named.

At the end stands a cut into waves, each of which delivers benefit on its own and can be stopped on its own.

Step 3: building the ground order of a cloud environment

3. Build the Ground Order

Account structure, network segmentation, identities and permissions, separation of test and production, logging and retention are set up.

The rules are described as code so that they can be checked and restored.

Only then does the first productive application move in — retrofitting at this point is the most expensive variant.

Step 4: the pilot wave of the cloud migration is being carried out

4. Run the Pilot Wave

One manageable but real application travels first — with data migration, sign-off by the business unit and a rehearsed way back.

The pilot wave delivers the dependable figures for effort, duration and running costs of the remaining waves.

Whatever does not work here is corrected before it multiplies across all later waves.

Step 5: further migration waves are running, operations are being built

5. Work Through the Waves and Operate

The following waves run on the same pattern; operations are built alongside instead of afterwards.

Your own people ride the waves with us, so that the knowledge grows where the environment is later run.

A wave only counts as finished once the old environment is switched off and nothing points at it any more.

Step 6: the cost control loop is installed and operations are handed over

6. Cost Loop and Handover

Consumption is allocated to applications and teams, pricing models are compared and reviewed monthly.

A few measurable figures stand from the outset: cost per application, provisioning time, share of compliant environments.

The date of the handover is settled before the first wave, and it holds: from that point the organisation runs the environment on its own.

Budget Frame

What Cloud Consulting Costs — and How Cloud Costs Can Be Planned

Two figures get confused easily in the budget of a cloud transformation: the fee for outside support and the running cost of the environment itself. Only the first can be quantified here. Our network invoices per day worked; there is no fixed project price and no share tied to the outcome.

Five things move the number. First the seniority and the decision proximity of the role: whoever owns a target architecture or defends a programme in front of the management board sits above a role that supplies. Next platform track record — there are few people who have already carried an exit of this order through twice, and that shortage moves the number more than anything else on this list. Then the industry: environments under evidence duties ask for experience that only a small circle brings. Where the work can be done from a desk — architecture, automation, cost analysis — the search reaches far beyond your own region and the rate softens; site and data centre work asks for presence. And finally the length of the engagement: spread over twelve months, the same onboarding pays for itself, which is why a long mandate prices lower per day than a four-week one.

The bands out of our own role roster, published openly on the respective pages. For operations and platform work €700 to €1,300 per day (Freelance Cloud Operations Manager, Freelance Platform Engineer, Freelance DevOps Engineer, Freelance Site Reliability Engineer). For relocation and data centre exit €750 to €1,400 (Freelance Data Center Migration Specialist, Freelance Cloud Migration Consultant). For cost stewardship €800 to €1,200 (Freelance Cloud FinOps Consultant). For architecture and ground order €800 to €1,500 (Freelance Infrastructure Architect, Freelance Hybrid Cloud Architect, Freelance Cloud Architect, Freelance Multi-Cloud Architect). For cloud security €900 to €1,400 (Freelance Cloud Security Architect). Each figure marks a band rather than a price tag; the number for one named assignment is settled in writing before anybody starts.

Release it section by section instead of as one sum. Four tranches have worked well, and each one closes on a decision that is explicitly permitted to be negative: the assessment of the application landscape, ending in a reasoned recommendation per application; the pilot wave, ending in hard figures for effort and running cost; the remaining waves, each closing with its own sign-off; and operations, closing on a monthly cost loop. Sign off the whole sum in one go and you give away exactly the moments at which changing direction would still have been inexpensive.

How this differs from hiring a system house or a platform partner. The gap sits in the object of purchase rather than in the invoice. A system house delivers a crew with its own method and its own tooling, and its revenue frequently rides on the products and licences it puts in place. Here a single seat is filled inside your own organisation, with no licence interest and no partner commission. In exchange you supply the technical lead yourself, and what the assignment produces in know-how settles inside the team that will run the environment afterwards. Never part of the rate are the running costs of the platform itself — consumption, licences, data transfer and operations hang on your architecture and your usage behaviour, not on the staffing.

Staffing follows the shape of the project: an assessment of the application landscape calls for a different profile than a data centre exit. The full overview sits under Cloud, Infrastructure & DevOps — among them Cloud Architects, Cloud Migration Consultants and FinOps Consultants. For operations after the move IT Service Management adds to it, for data platforms on the new environment Data Engineering & Data Science, and for running models on top of it AI consulting.

90 %

of companies in Germany use cloud applications — a year earlier it was 81 %.

Bitkom Cloud Report 2025

53 %

of the cloud-using companies see themselves at their providers' mercy on pricing and contract terms.

Bitkom Cloud Report 2025

52.7 %

of companies in the EU bought paid cloud services in 2025; in 2023 it was 45.3 %.

Eurostat

Cloud consulting — also traded as cloud advisory — settles which parts of an application landscape are better placed in a cloud environment, in which order they get there, and how the environment is led afterwards. That includes the assessment of the existing applications, the ground order of the new environment with rules for network, identities and data residency, the cut of the migration waves and the ongoing cost stewardship. It is vendor-neutral where it earns nothing from selling licences or managed services.

A cloud migration is the relocation of applications and data out of your own data centre into a cloud environment. It runs in waves: first the application landscape is recorded and it is decided per application whether it travels unchanged, gets rebuilt beforehand, is retired or is deliberately left standing. Then the ground order of the target environment is created, a pilot wave follows with a real application and a rehearsed way back, then the remaining waves. A wave only counts as complete once the old environment is switched off; keeping that sequence honest is what cloud migration consulting is for.

When a fixed date forces the decision — expiring hardware, an ending site contract, an announced end of support. When a relocation of this size has never been done in-house. When the invoice of a running environment can no longer be attributed to anyone. Or when evidence on storage location, access routes and exit capability is demanded. Where the landscape is manageable and both experience and capacity sit in the house, outside support mostly costs coordination.

Rarely on the technology. More often because a grown landscape is relocated unchanged and carries its idle capacity along, which is now billed monthly. Or because nobody is named who is allowed to switch an environment off — then none gets switched off. Further recurring causes: a ground order that is only retrofitted afterwards, and a missing handover from the project into operations.

The question cannot be answered for a company as a whole, only per application. What decides is the load profile, the data category, the dependencies on neighbouring systems, the operating knowledge available and the question of how tight a tie to one provider is bearable. Out of that comes a public cloud for one application, a private environment for the next, and staying in your own data centre for the third. This assessment belongs before the platform decision, not after it.

Security in the cloud is shared responsibility: the provider secures the platform, the company secures its own configuration — permissions, encryption, key management, logging, network segmentation. Most incidents arise in that second half. Sovereignty asks where data sits, who can reach it and how it leaves an environment again. Both belong in the architecture; the legal assessment of individual data categories stays a case-by-case review. The depth on protective measures belongs to a dedicated security mandate.

The bands on our role pages run from €700 for roles in running operations up to €1,500 for architecture and programme accountability. Five things settle the position within a band: seniority, platform track record, industry, how much of the work can be done remotely, and the length of the engagement. A dependable figure only comes out of the cut of the role. The same task can be cut as a supply position or as a co-accountable one, and the difference moves in the three-digit range per day. Which band applies to which role is published openly on the role page.

The effort hangs on the number of applications, their dependencies and on how much gets rebuilt beforehand — it only becomes dependable with the pilot wave, which exists for exactly that. Besides the fee, three blocks fall due that are regularly missing from early calculations: the running costs of the target environment, which stay after the project and move with usage; internal effort for business units, testing and sign-off; and parallel operation during the waves, in which both sides are paid at once. For planning, therefore, a total sum counts for less than the question of when the old environment is really switched off.

You can rely on us

Excellent. We are not the only ones who think so.

consultingheads has received several awards from leading trade magazines and independent third parties.

consultingheads-award-top-company-2025-kununu

consultingheads-kununu-top-company-2023 (1)

Next Step

Let's talk about your route into the cloud.

A rough placement of your application landscape in twenty minutes

One concrete next measure instead of a presentation

Free of charge and without sales pressure

A short conversation in which we sort your application landscape roughly and name which wave opens the sequence — and whether we have the right people in the network for it.