The SaaS Replacement Scorecard

A SaaS product is a good replacement candidate when the workflow is narrow, stable, expensive relative to its value, and supported by someone who can own the replacement. Hosted software remains the better choice when it carries hard integrations, regulatory duties, high failure costs, or a feature set the business keeps expanding.

This scorecard makes the tradeoffs explicit before an easy first demo distorts the comparison.

The five gates

Each gate receives 0, 1, or 2 points.

Gate	0 points	1 point	2 points
Workflow	Broad, changing, poorly understood	Several stable jobs with some uncertainty	One narrow, repeated, well-understood job
Data	Hard to export or deeply entangled	Export exists but needs cleanup	Clean export, clear ownership, simple model
Failure cost	Revenue, safety, compliance, or customers at immediate risk	Recoverable disruption with a manual fallback	Low-risk and easy to replay or correct
Ownership	No operator or maintenance budget	Part-time owner with outside help	Named technical owner and operating routine
Economics	Subscription is cheap relative to value	Savings depend on optimistic assumptions	Three-year cost has a wide, conservative margin

The total suggests:

• 0–3: keep the current product or switch to another hosted product.
• 4–6: investigate an existing open-source product and run a small prototype.
• 7–8: a narrow custom build deserves a real estimate.
• 9–10: strong replacement candidate, subject to security and migration review.

The score starts a conversation. A zero in failure cost or ownership can veto a high total.

Gate 1: The workflow is narrow and stable

The job should fit into a sequence a new employee could follow, with its inputs, decisions, outputs, exceptions, and people named.

“Replace our CRM” is too large. “Capture referrals, assign an owner, record the next action, and remind the owner after three days” can be estimated and tested.

A stable workflow can still change, but the business can distinguish required behavior from ideas that surfaced during the conversation. A replacement that begins with an unsettled process becomes a custom software project with an unlimited backlog.

Gate 2: The data can leave cleanly

Planning should begin with a real data export. The review covers rows, attachments, relationships, missing fields, duplicates, ownership, retention, and deletion requirements.

An API helps during transition and coexistence. A documented bulk export provides a reliable exit. Dashboard screenshots can’t replace either one.

Migration complexity often determines whether the project works. A simple application with ten years of messy records can be harder to replace than a sophisticated product with a clean export.

Gate 3: Failure is recoverable

The failure review should cover a full day of downtime and a bug that silently writes the wrong value for a week.

The consequences and manual fallback need to be explicit. Scheduling, surveys, internal approvals, and lightweight tracking often have recoverable failure modes. Payroll, payments, clinical records, identity, tax filing, and safety systems carry different stakes.

The team needs enough operating capacity to detect, contain, correct, and learn from a failure.

Gate 4: Ownership continues after launch

Each duty needs a named owner:

• dependency and security updates;
• access reviews and account removal;
• backups and restore tests;
• uptime and error monitoring;
• user support and bug triage;
• data exports and retention;
• vendor API changes;
• feature decisions.

AI agents can perform much of this work. A person still chooses when to run them, reviews risky changes, pays the hosting bill, and answers when production breaks.

Gate 5: Conservative cost math works

A three-year view is more useful than comparing this month’s subscription with this week’s model bill.

The SaaS estimate includes seats, usage charges, add-ons, integrations, administration, and expected increases. It also credits bundled features the business would otherwise have to replace.

The owned estimate includes discovery, build time, data migration, security review, hosting, email or messaging, monitoring, backups, support, maintenance, major upgrades, and human time.

The margin should survive a slower build and a higher maintenance estimate. A break-even case built on best-case assumptions doesn’t justify replacing the current product.

Four possible exits

The scorecard may show that the current product should go. A separate comparison determines what replaces it.

1. Keep: renegotiate, remove seats, downgrade, or fix the workflow around the product.
2. Switch: move to a hosted product with a better fit or pricing model.
3. Self-host: operate mature open-source software.
4. Build: create the smallest system that performs the stable job.

A useful sequence begins with the cheapest reversible option. A plan downgrade teaches more about required features. A hosted trial exposes migration problems. A self-hosted demo shows the real administration work. A narrow prototype tests whether the process was understood.

The written decision

The decision record includes the score, assumptions, owner, sources, date, and the condition that would change the verdict: a price increase, a new integration requirement, ticket volume, a regulatory constraint, or the loss of the technical owner.

That record prevents the team from relitigating the decision whenever a new coding model ships.