Imagine this: Your most important IT system fails. The cloud provider has issues. Or ransomware. Or something unexpected.

The classic question is: "How quickly can we recover?"

The better question is: "How can we continue working while recovering?"

That is the difference between Disaster Recovery and Minimum Viable Operations.

The Problem with Perfect Redundancy

Everyone wants 100% availability. Clearly.

But let's talk about costs.

To make a system truly 100% redundant, you need:

• Double infrastructure (second data center, second cloud provider)

• Active data replication in real-time

• Automated failover mechanisms

• Regular tests of failover scenarios

• Staff familiar with both environments

For a medium-sized enterprise with a revenue of CHF 50M? That quickly costs CHF 200K-500K per year. Per critical system.

And here's the uncomfortable truth: Most companies don't have just one critical system, but five or ten. Perfect redundancy for everything is simply unaffordable.

The 70% Rule

Here's the pragmatic approach:

70% capacity within 30 minutes protects more revenue than 100% capacity after 48 hours.

Let that sink in for a moment.

If you take 48 hours to get back to 100%, you've made zero revenue for 48 hours. For an e-commerce company with CHF 180K daily revenue, that's a CHF 360K loss.

If instead, you can switch to 70% capacity within 30 minutes, you might lose about CHF 15K during the switch and then continue operating at reduced capacity.

That is MVO: Not perfect, but functional.

What is Minimum Viable Operations?

MVO is the answer to the question: "With what reduced capacity can we continue working while solving the actual problem?"

It's not about keeping everything running perfectly. It's about defining the minimum that keeps the business operational.

For each critical process, define:

The beauty of it: MVO forces you to distinguish between nice-to-have and must-have. This clarity is also valuable in normal operations.

How to Define MVO: 4 Steps

Step 1: Identify Critical Processes

Start not with IT. Start with the business.

Ask yourself:

• Which processes generate direct revenue?

• Which processes have regulatory consequences if they fail?

• Which processes directly affect customers?

Typical candidates:

• Order intake and processing

• Production (for manufacturing companies)

• Payment processing

• Customer service (for critical inquiries)

• Supply chain coordination

If you've already done a Business Impact Analysis, use it as a basis.

Step 2: Define the Minimum

For each critical process: What is the absolute minimum needed to continue working?

Specific questions:

1. Minimum Capacity: At what percentage of normal capacity can we operate without existential damage?

2. Nice-to-Have vs. Must-Have: What features are comforts, which are essential?

3. Manual Workarounds: If system X fails – can we continue manually? With which tools? How long is that feasible?

4. Priority with Resource Scarcity: If we only have 50% of our staff – who does what?

A practical example:

Production at an industrial company:

• Normal: 1000 units/day with fully automated production

• MVO: 700 units/day with reduced quality checks (only stages 1+2, not stage 3) and manual packaging

• What is eliminated: Stage 3 quality checks, automated packaging

• What remains: Core production, basic quality control

• Acceptable Duration: 5 days

Step 3: Develop Fallback Options

Now it gets concrete: What is Plan B if the primary method fails?

Fallback Options Template:

Questions for each fallback option:

1. Alternative Technology: If system A fails, what other platform can we use?

2. Alternative Suppliers: If supplier X doesn’t deliver, is there a supplier Y?

3. Manual Processes: Can we operate manually for a while?

4. Reduced-Feature Mode: Can we continue with 70% functionality?

5. Activation Time: How quickly can we switch over? Who decides?

Step 4: Test Regularly

An MVO plan that is never tested is just hope.

Define test scenarios:

Important when testing:

• Tests should be announced (no surprise), but with real time pressure

• Document: What worked? What didn’t?

• After each test: Update plan, improve fallback options

• Also test: Who makes decisions? Who communicates?

Practical Example: MVO in Action

An e-commerce company with CHF 45M annual revenue (~CHF 180K daily revenue). The main shop runs on AWS.

The initial situation:

• Shop on AWS EU-Central-1

• No fallback options defined

• In case of AWS failure: Total outage

After MVO Definition:

Fallback Strategy:

• Option 1 (Activation: 30 Min): Emergency landing page on Azure with "Order now by phone" + hotline expansion. Allows reduced order processing.

• Option 2 (Activation: 2 Hrs): Basic shop on Azure with reduced features (main products only, no customization). Allows ~70% normal capacity.

Preparation Costs:

• Emergency landing page + Azure setup: CHF 15K one-time

• Annual maintenance: CHF 5K

• Hotline expansion agreement: CHF 3K/year

Result in the First Outage:

• AWS outage lasted 6 hours

• After 30 min: Hotline active, emergency site online

• After 2 hrs: Basic shop on Azure

• Revenue loss: CHF 15K (instead of estimated CHF 45K in total outage)

ROI: The CHF 23K investment paid off threefold at the first incident.

The Mindset Shift

MVO requires a change in thinking for many executives.

Old Mindset: "In case of failure, we need to get back to 100% as quickly as possible."

New Mindset: "In case of failure, we need to keep operating functionally as quickly as possible - even if it's not perfect."

Initially, this feels uncomfortable. Nobody wants to tell customers "Our shop is currently available with limitations." But it's better than "Our shop is not available at all."

Common Objections (and Why They Are Wrong)

"Our customers expect 100% availability."

Do they? Or do they expect you to communicate transparently about problems and still offer a solution? Experience shows: Customers are surprisingly tolerant of temporary limitations – if you communicate proactively and offer an alternative.

"Manual workarounds are too error-prone."

Yes, they are more error-prone than automated systems. But an error-prone process that runs is better than a perfect process that doesn't. You don't plan MVO for continuous operation – but for bridging the gap.

"It's too cumbersome to document."

A 5-page MVO plan that is tested quarterly beats any 50-page plan that is never tested. Keep it simple. One table per critical process is enough.

The Short Version

• MVO answers: With what minimum capacity can we continue working?

• The 70% Rule: 70% immediately protects more revenue than 100% after 48 hours

• Nice-to-Have vs. Must-Have: MVO enforces clarity

• Fallback Options: Define Plan B (and C) for every critical process

• Test, test, test: An MVO plan without testing is just hope

What Now?

Take one critical business process. Only one.

Answer these questions:

1. What is the normal capacity?

2. What is the absolute minimum (MVO)?

3. What can be eliminated?

4. What needs to stay?

5. How long is MVO acceptable?

Once you've thought this through for one process, you've understood the principle. Then do it for the remaining critical processes.

(And if you notice that you need support to systematically work through this for all critical processes – that's what we're here for.)

Further Reading

• Why Your Business Continuity Plans Fail in an Emergency – The Problem with Traditional DR

• The 5 Dimensions of Operational Resilience – The Complete Framework

• Business Impact Analysis: Identifying Critical Business Processes – The First Step