Should This Product Even Move to the Cloud?

“We should move this product to the cloud.”

It sounds like progress. After all, many of the products we use every day depend on cloud infrastructure, and moving away from company-managed servers can appear to be the obvious next step for a growing product.

But there is a problem with starting there.

Moving to the cloud is not a business goal.

It is a technology decision that should help us achieve a business or customer goal.

That distinction is important for Product Managers because the conversation can otherwise jump very quickly from “we should use the cloud” to AWS versus Azure, migration plans, containers, databases, and architecture diagrams.

Before discussing any of those, I would ask a much simpler question:

What problem will moving this product to the cloud actually solve?

If we can answer that clearly, we have the beginning of a useful cloud conversation. If we cannot, choosing a cloud provider is probably premature.

So, should a product move to the cloud?

A product should move to the cloud when cloud capabilities solve an important customer or business problem better than realistic alternatives, and when the expected value is worth the cost, complexity, and migration risk.

Sometimes the answer will be yes.

Sometimes it will be no.

And quite often, the best answer will be: move some things, but not everything.

Let’s understand why.

A cloud migration can start with a very non-cloud problem

3M offers an interesting example.

According to an AWS case study, the company was operating aging data centers, and getting additional hardware capacity could be difficult. 3M eventually embarked on a large cloud migration programme and moved more than 2,200 applications to AWS in 24 months.

One of the reported outcomes is particularly interesting from a Product Manager’s perspective: resources that previously took weeks to deploy could be deployed in minutes after the migration.

Forget AWS for a moment.

Look at the underlying problem.

The organisation needed infrastructure, but obtaining that infrastructure could take weeks.

That means infrastructure provisioning itself had become a constraint.

This is a much better starting point for a Product Manager than:

“We need cloud.”

The useful question becomes:

Is our current technology environment preventing the business from moving at the speed the product requires?

Perhaps engineers wait weeks for test environments. Maybe additional capacity cannot be added quickly when customer demand increases, or entering a new market requires months of infrastructure preparation.

Those are measurable problems.

Once the problem is clear, cloud becomes one of the options we can evaluate.

Start with what the business is trying to change

Imagine that leadership tells you the product needs to move to the cloud.

Before asking which provider to use, ask what success would look like.

Maybe the business wants to support rapid customer growth. Perhaps infrastructure costs are becoming difficult to manage, reliability needs to improve, or engineering teams spend too much time maintaining infrastructure instead of building customer-facing capabilities.

Each problem creates a different reason to consider cloud.

For example:

“Move 100% of workloads to the cloud” tells us what activity will happen.

“Reduce infrastructure provisioning from three weeks to one day” tells us what outcome we want.

Similarly:

“Migrate our application to AWS” describes implementation.

“Maintain acceptable performance when traffic increases tenfold” describes the problem the product needs to solve.

This distinction sounds small, but it changes how the entire initiative is evaluated.

Would the customer notice anything?

Infrastructure decisions are often invisible to users.

Imagine receiving this notification from one of your favourite products:

“Great news! We migrated our infrastructure to the cloud.”

Unless you work in technology, you probably wouldn’t care.

Now imagine the message said:

“The product now responds faster and is available in your region.”

That is different.

Pipedrive provides a useful real-world example. According to an AWS case study, the CRM company’s private-cloud environment was becoming difficult to scale as its customer base and global reach grew.

Following its AWS migration, Pipedrive reported a 25% reduction in response times and up to a 20% reduction in hosting cost per customer.

The interesting part for a Product Manager isn’t simply that Pipedrive adopted cloud infrastructure.

It’s that two outcomes can be connected to the product:

customers received faster responses, while the economics of serving each customer improved.

That gives us a useful test:

If we move this product to the cloud, what becomes meaningfully better for the customer?

Maybe pages load faster. Perhaps the product becomes more reliable, expands into another geography, recovers from failures faster, or can handle sudden demand without becoming unusable.

If the customer gets nothing and the business gets nothing, migration becomes much harder to justify.

Does your product actually have a scaling problem?

Cloud and scalability are often mentioned together, so let’s make the idea very simple.

Imagine a restaurant with 20 tables.

Most days, 15 tables are enough. But every Saturday evening, 200 customers arrive at the same time.

The restaurant has a capacity problem.

Software products can experience something similar.

A ticket-booking product may have moderate traffic throughout the week, followed by an enormous spike when tickets for a popular event go on sale. An e-commerce product may see the same pattern during a major sale.

Cloud infrastructure can make it easier to increase computing capacity when demand rises and reduce it when demand falls. When this happens automatically, the capability is commonly called autoscaling.

But now consider an internal payroll application used by 2,000 employees. Its demand may be highly predictable, and the number of users is unlikely to increase fiftyfold tomorrow.

Both products could run in the cloud, but they do not have the same reason for being there.

A Product Manager should therefore push beyond:

“We need scalability.”

Ask:

How much traffic do we receive today?

How quickly can it change?

What do we expect over the next few years?

What happens to the customer experience when demand exceeds capacity?

Once those questions have numbers behind them, scalability becomes a requirement rather than a buzzword.

“Cloud will save us money” needs evidence

Cost is another common reason organisations consider cloud migration.

The argument sounds straightforward: if we stop buying and maintaining our own servers, infrastructure should become cheaper.

Reality is more nuanced.

Running company-managed infrastructure can involve hardware purchases, storage, networking equipment, data-center space, maintenance, software licences, power, cooling, and teams responsible for keeping everything operational.

Cloud changes that model because infrastructure can be consumed as a service.

However, cloud introduces its own costs. Computing capacity, databases, storage, backups, network traffic, monitoring, logs, support, and managed services can all contribute to the bill.

A real healthcare example shows why the comparison needs to go deeper.

ACCESS Community Health Network reported that aging on-premises infrastructure required hardware refreshes costing roughly $400,000 every three to five years, while some third-party software licensing costs had also increased significantly.

According to Microsoft’s customer case study, after moving workloads to Azure, ACCESS eliminated more than $300,000 in third-party licensing costs.

Those numbers should not be interpreted as proof that cloud is always cheaper; they are vendor-reported results from one organisation with a particular starting point.

The lesson is different.

You cannot evaluate cloud economics without understanding what the current environment really costs.

For a Product Manager, that means moving beyond “server cost” and looking at the total cost of ownership (TCO).

Then connect infrastructure spending to the product itself.

Useful questions include:

What does infrastructure cost per active customer?

What does it cost per transaction?

How does infrastructure spending change as usage grows?

What happens to gross margin?

Cloud cost becomes far more meaningful when it is connected to product economics.

Sometimes the biggest benefit is speed

Cloud discussions often focus on cost and scalability, but speed can be just as important.

Return to the 3M example. Reducing infrastructure deployment from weeks to minutes is not simply an infrastructure improvement.

Think about what happens downstream.

An engineering team receives an environment sooner, which means it can begin development or testing sooner. Experiments can run earlier, teams learn faster, and useful features can potentially reach customers sooner.

The business value therefore isn’t:

“We can create infrastructure quickly.”

The value is closer to:

“Infrastructure no longer slows down how quickly we can learn and deliver.”

That is a much more interesting Product Management conversation.

How expensive is one hour of downtime?

Now consider reliability.

Mantrac, a heavy-equipment company operating across multiple countries, had an existing disaster-recovery setup that made transferring systems between data centers difficult.

According to a Microsoft customer case study, after moving its disaster-recovery environment to Azure, Mantrac reported shorter downtime and roughly 50% lower IT costs.

Again, the lesson isn’t that every company should copy Mantrac’s architecture.

The Product Manager question comes before architecture:

What happens to our business when this product is unavailable?

For one product, an hour of downtime may be inconvenient.

For another, it could mean lost transactions, SLA penalties, customer churn, employee downtime, support demand, or damage to customer trust.

This is why Product Managers should understand terms such as availability, SLA, RTO, and RPO, even if they never configure infrastructure themselves.

These concepts help translate technical resilience into business expectations.

Only after understanding the impact of failure can the organisation sensibly decide how much resilience it should pay for.

Cloud can sometimes change the product itself

This is one of the more interesting possibilities.

Orbit Healthcare provides an example.

According to Microsoft’s case study, its private-cloud environment could not automatically scale in the way the company wanted and was limiting its ability to provide real-time API services.

After moving to Azure, Orbit reported being able to offer real-time services and shift from a pricing model based largely on seats or devices toward transactional pricing.

Think about what happened there.

Infrastructure didn’t simply become faster.

Infrastructure capability helped enable a different product and business model.

That is worth remembering because the best cloud business case may not always be “reduce infrastructure cost.”

Sometimes the question is:

What product capability becomes possible that we cannot reasonably provide today?

That can be a much more powerful reason to consider migration.

Security doesn’t disappear when infrastructure moves

There is another misconception worth addressing:

“If we move to a major cloud provider, security becomes their problem.”

It doesn’t work that way.

Cloud providers secure many parts of the underlying infrastructure, while customers remain responsible for how they configure and use cloud services. This division is commonly described as the shared responsibility model.

For a Product Manager, the important questions are practical.

What information does the product handle? Who should be able to access it? Where is it allowed to be stored? How is sensitive information protected? What happens when an employee leaves? What audit evidence must enterprise customers receive?

Consider a customer saying:

“Our data must remain inside this country.”

That may sound like a legal requirement, but it can quickly become an architecture requirement because it affects where information is stored, backed up, replicated, and processed.

This is why data residency, privacy, security, and compliance should be understood before migration decisions are finalised.

Moving an old product is not the same as building a new one

A new product starts with relatively little history.

A ten-year-old product doesn’t.

Over time, systems accumulate integrations, databases, libraries, scripts, processes, workarounds, and dependencies. Some are well documented; others may be understood only by the person who built them years ago.

Moving such a system can reveal surprises.

Adobe offers an example of how significant migration planning can become. In an AWS case study, Adobe reported migrating the database supporting one of its collaboration services within six months while maintaining virtually zero downtime and reducing costs by 40%.

The “virtually zero downtime” part matters.

For a live product, migration success isn’t simply:

Did the data move?

It is also:

Could customers continue using the product safely while it moved?

That introduces questions about testing, rollback, data consistency, compatibility, and migration sequencing.

It also raises another important question:

Does everything need to move?

Some workloads may be good cloud candidates. Others may need to be modernised first, remain where they are, or simply be retired.

Cloud migration doesn’t have to be all or nothing.

How I would make the decision

After looking at the business problem, users, workload, and constraints, I would evaluate the product across seven areas.

I would then compare at least three possibilities rather than forcing the decision into yes or no:

Stay where we are.

Move selected workloads to cloud.

Move most or all appropriate workloads to cloud.

For some products, a hybrid cloud approach may make more sense because certain systems can move while others remain in existing environments.

The point is not to select the option with the most modern architecture.

The point is to select the option that creates the strongest value after accounting for its trade-offs.

Something I learned while working through architecture decisions

As I have worked through technical product and solution-architecture problems, I have noticed how easy it is to start with technology.

Architecture diagrams are especially tempting. Within minutes, we can have boxes representing APIs, databases, storage, containers, queues, caching, monitoring, networking, and AI services.

The diagram may look impressive, but it still cannot answer the most important question:

Are we solving the right problem?

I now find it much more useful to work backwards:

Business outcome → User problem → Workload → Requirements → Constraints → Capabilities → Architecture options

Only after those pieces are reasonably clear do specific technologies become useful to discuss.

This changes the conversation from:

“How can we move this application to the cloud?”

to:

“What problem would moving it solve, and is cloud actually the best way to solve it?”

It is a small change in wording, but it leads to a very different quality of decision.

How would we know the migration worked?

Imagine that six months after the project begins, leadership announces:

“Success. All our workloads are now in the cloud.”

Is that success?

Not necessarily.

The number of workloads migrated measures what the team did. It doesn’t tell us whether the original problem improved.

If slow delivery justified migration, we might measure infrastructure provisioning time, deployment lead time, or release frequency.

If reliability was the problem, we might track availability, incident frequency, and recovery time.

If scalability drove the decision, customer-facing latency and failed requests during peak demand become important.

If economics were the motivation, metrics such as infrastructure cost per customer, cost per transaction, and gross margin become much more useful than the total monthly cloud bill alone.

Success should always connect back to the reason the organisation moved.

When should you move to the cloud?

Moving to the cloud deserves serious consideration when the current environment is preventing the product from achieving an important business or customer outcome and cloud capabilities provide a credible way to remove that constraint.

That might mean supporting unpredictable growth, entering new markets faster, improving disaster recovery, reducing infrastructure provisioning time, accessing managed capabilities, or changing the economics of operating the product.

But cloud adoption should not happen simply because cloud is modern.

A predictable workload running efficiently on existing infrastructure may not have an urgent migration problem. A system tied closely to specialised hardware may also have good reasons to remain where it is, while regulatory or data-location requirements may change which cloud options are realistic.

Sometimes the right decision is:

Move.

Sometimes it is:

Don’t move yet.

And sometimes it is:

Move this part, but leave that part alone.

All three can be good product decisions.

Questions a Product Manager should ask before saying yes

Before recommending a cloud migration, I would want clear answers to these questions:

• What business problem are we solving?
• What becomes better for the customer?
• What evidence shows the current infrastructure is limiting us?
• How does our workload behave today, and how might it change?
• What does the current environment actually cost?
• What would the realistic cloud alternative cost?
• What reliability level does the product need?
• What security, privacy, and regulatory constraints apply?
• Which dependencies make migration difficult?
• What happens if the migration fails?
• Could only part of the product move?
• What metrics will tell us whether the decision worked?

If the team cannot answer these yet, that does not mean cloud is the wrong decision.

It means the decision needs more discovery.

Frequently Asked Questions

Should every product move to the cloud?

No. A product should move when cloud capabilities solve an important customer or business problem better than realistic alternatives and the expected value justifies the cost, complexity, and migration risk.

Is cloud always cheaper than on-premises infrastructure?

No. Cloud economics depend on workload behaviour, utilisation, architecture, storage, network traffic, licensing, operational costs, and the existing infrastructure. Product teams should compare total cost and unit economics rather than assuming cloud will automatically reduce spending.

What should a Product Manager evaluate before cloud migration?

At minimum, evaluate business value, customer value, workload behaviour, scalability, economics, reliability, security and compliance, dependencies, and migration risk.

Does the entire product need to move to the cloud?

No. Different workloads can have different requirements. A phased or hybrid approach may be better when only some components benefit from cloud capabilities.

Does a Product Manager need to understand cloud architecture?

A Product Manager does not need to replace a Cloud Architect. However, understanding enough cloud terminology and architecture to connect technical trade-offs with customer value, cost, reliability, risk, and business outcomes can improve product decisions.

How should cloud migration success be measured?

Measure the outcome that originally justified migration. Depending on the problem, useful metrics might include provisioning time, deployment lead time, availability, recovery time, latency, infrastructure cost per customer, engineering productivity, or customer experience.

The question worth remembering

There will be plenty of time to discuss AWS, Azure, Google Cloud, containers, Kubernetes, serverless, regions, databases, networking, and the dozens of other concepts that make cloud computing interesting.

Those decisions matter, but they come later.

The first question is much simpler:

Should this product even move to the cloud?

Start with the business outcome. Understand the customer, workload, current limitations, economics, and constraints. Compare realistic options and make the trade-offs visible before choosing the technology.

Because moving to the cloud is not the goal.

Creating a better outcome for the customer and the business is.

Glossary terms to internally link

When the relevant VulpisLab glossary pages are available, internally link the first meaningful occurrence of terms such as:

Cloud computing, cloud migration, autoscaling, compute, total cost of ownership (TCO), availability, SLA, RTO, RPO, shared responsibility model, data residency, hybrid cloud, workload, infrastructure provisioning, latency, disaster recovery, CapEx, OpEx, region, availability zone, serverless, containers, and Kubernetes.