Selling cloud to a company that has run its own data centre for fifteen years is not a technical problem. It is a trust problem, a risk problem and a language problem, in that order. The framework below moves these deals forward: start with their business constraint rather than the product, translate every technical capability into an outcome, bring the architect in early, run a narrow proof of concept with agreed criteria, build the total cost case in numbers the board already uses, and treat the signature as the start of the work rather than the end.
Why traditional enterprises are the hard case
Most cloud sales material is written for startups and digital natives, where the buyer already believes and the conversation is about which service. The harder and more valuable case is the organisation with a twenty-year-old estate, a conservative infrastructure team, a finance director who remembers every vendor promise that did not hold, and a board that treats «cloud» as a word from a conference.
Across Central Asia and Eastern Europe most large enterprises still run their own facilities. Convincing them to move is rarely blocked by architecture. It is blocked by who carries the risk if it goes wrong.
Step 1. Open with their constraint, not your product
The first meeting should contain no slides about services. Three questions do more than any deck: what is the infrastructure problem that costs you most right now, when was the last significant outage and what did it cost, and what initiative is currently on hold because the current setup cannot support it.
The goal is a specific constraint rather than an abstraction. Not «cloud migration» but something like: we need to launch in a neighbouring market within six months and building a facility there takes eighteen. Write that sentence down. Every subsequent conversation returns to it.
The moment a conversation opens with instance pricing or storage tiers, the room is lost. Enterprise buyers do not buy infrastructure; they buy the removal of a constraint they have already named to their own board.
Step 2. Translate capability into consequence
Every technical property has a business form, and only the business form survives the meeting.
Cross-region replication is not a feature; it is the answer to the question the technical director asked about what happens when a facility fails. Elastic capacity is not a specification; it is not crashing during the campaign peak while not paying for idle hardware the rest of the year. Compliance certifications are not a list; they are the audit conversation ending earlier.
The exercise worth doing before any proposal: write the customer’s problem in the left column, the service in the middle, and the business consequence on the right. If the right-hand column is empty for any row, that row does not belong in the proposal.
Step 3. Bring the architect in early
A mistake worth naming plainly: trying to field every technical question personally in order to look competent. It fails, and it fails visibly — the customer’s infrastructure team can tell when someone is improvising.
The better move is a joint working session where the architect works through the customer’s actual architecture with the customer’s actual engineers. This is worth more than several presentations, because it changes the frame from being sold to being helped.
In these sessions, limitations get stated rather than avoided. Where data residency rules constrain what can move, saying so early is what makes the rest of the proposal credible. A hybrid design that acknowledges the constraint beats an elegant one that ignores it.
Step 4. Run a proof of concept, not a demonstration
A demonstration shows what the product can do. A proof of concept shows what it did with the customer’s data, and only the second one changes minds.
Design it narrowly: one specific pain point from step one, a two-to-four week window, success criteria agreed in writing before it starts, and the customer’s own engineers involved in the build. Where trial credits or free-tier capacity apply, use them — removing financial risk from the experiment removes the last easy objection.
The debrief matters as much as the result. «We moved the reporting workload, response time under simulated peak improved by a measured amount, and when we simulated a facility failure the system recovered in minutes against the current recovery time of hours» is evidence. Evidence is what gets repeated in the meeting you are not in.
Step 5. Build the cost case in their numbers
After a successful proof of concept the technical team is usually convinced and the remaining obstacle is financial approval. This is where total cost of ownership stops being a document and becomes the deal.
The comparison has to include the on-premise costs that never appear on a server quote: hardware refresh cycles, power and cooling, floor space, maintenance contracts, the staff hours spent keeping infrastructure running, and the cost of an hour of downtime. Against that sits a model with no upfront capital, payment for actual consumption rather than peak capacity, committed-use discounts for stable workloads, and no refresh cycle to plan.
One cost is consistently underweighted and consistently decisive in this region: the difficulty of hiring and retaining people who can run infrastructure locally. That does not appear in any quote, and it is often the argument that lands hardest with the executive who has been trying to fill the role.
Step 6. The contract is the beginning
The most expensive mistake in cloud sales is treating signature as the finish line. For a traditional enterprise the first ninety days determine whether this becomes a long relationship or a cautionary story told to peers.
What that period requires: monitoring and alerting configured before go-live rather than after the first incident, training for the customer’s engineers, monthly check-ins that report business metrics rather than only technical ones, and a quarterly review measured against the constraint named in step one.
Then the next initiative. Once an organisation has seen one workload work, the conversation shifts from whether this can be trusted to what else can move — and that is a different sale entirely.
Key points
- The obstacle is trust and risk ownership, not technical capability.
- Anchor on one named business constraint and return to it in every conversation.
- Any capability without a business consequence does not belong in the proposal.
- Joint architecture sessions outperform presentations; stated limitations build credibility.
- Proof of concept with pre-agreed criteria produces evidence that travels without you.
- Total cost must include refresh cycles, facilities, staff hours and downtime — and local hiring difficulty.
How long does this kind of deal take?
Months rather than weeks, and compressing it usually means skipping the proof of concept — which is the step that produces the evidence the finance conversation depends on. Time spent there is recovered in the approval stage.
What if data residency rules block the migration entirely?
They rarely block everything. The usual outcome is a hybrid design where regulated data stays local and compute moves, which is a legitimate architecture rather than a compromise. Establishing the constraint early is what makes that design credible rather than defensive.
Who is the real decision maker in these organisations?
Usually not the person who runs the pilot. The technical team can stop the deal but rarely approves it; the approval sits with whoever owns the budget and the risk. Both need different arguments, prepared in parallel rather than sequentially.
How do you handle a team loyal to their existing setup?
By not arguing with the loyalty. It is usually rational — the system works and they built it. The productive question is what they cannot do today that the business is asking for, which moves the conversation from replacement to capability.
Материал обновлён 5 сентября 2026