Razor SharpConsultingStart a project A guide for software owners
Do not choose a rewrite because software is old or frustrating. Start with the business dependency, support risk, data, integrations, and the result worth improving. Then choose the smallest modernization path that can reduce risk or create useful value.
Make the choice explicit
A system can need more than one path. For example, retain the accounting platform, wrap its supported API, rebuild one field workflow, and retire a duplicate spreadsheet process.
Keep a supported system when it still serves the business, its risks are understood, and change would not create enough value. Name an owner, monitor its condition, and set a date or trigger for the next review.
Repair reliability, testing, deployment, documentation, or support gaps when the underlying workflow still fits. Stabilization should reduce immediate risk and create evidence for the next decision, not become permanent emergency maintenance.
Keep a dependable core while adding an API, integration layer, automation, or modern interface around it. This can improve a high-friction workflow without forcing every user and dependency through the same cutover.
Choose a configurable platform or SaaS product when the capability is common and the product genuinely fits the workflow. Verify data portability, access controls, integration limits, ongoing fees, support, and an exit path before committing.
Build custom software when important business logic differentiates the operation and the current system cannot be supported or changed safely. Replace one coherent workflow at a time unless the evidence makes a larger cutover unavoidable.
Remove a system that no longer has enough use or business value. Archive required records, revoke credentials, update inventories, and watch for hidden dependencies before the final shutdown.
Evidence before architecture
The application is only part of the operating model. People, spreadsheets, reports, scheduled jobs, vendor connections, and undocumented exceptions may carry just as much business logic as the code.
Decision matrix
These are starting signals, not automatic prescriptions. Dependencies, security exposure, data quality, support status, and business timing can change the right answer.
| What you find | Likely path | Evidence before approval |
|---|---|---|
| The system is supported, stable, and still fits the work. | Retain | An accountable owner, current recovery evidence, monitored risks, and a review trigger. |
| The workflow is sound, but releases, reliability, or support are fragile. | Stabilize | Incident patterns, component support status, a test baseline, and a prioritized risk plan. |
| The core is dependable, but handoffs, access, or the user experience create friction. | Wrap and connect | Supported integration points, data ownership, failure handling, and a clear system of record. |
| The capability is common and a product fits the real workflow. | Replace with a product | Configured workflow proof, security review, full operating cost, data portability, and an exit plan. |
| Unsupported technology or rigid architecture blocks an important, differentiating workflow. | Rebuild a bounded slice | Preserved behaviour, acceptance measures, migration and rollback plans, and ongoing product ownership. |
| The system has little active use, no owner, or duplicates another capability. | Retire | Usage and dependency evidence, retention requirements, archive access, and secure decommissioning steps. |
Reduce cutover risk
Modernization should produce a useful business result while keeping the affected operation observable and recoverable. Cloud hosting or a new framework does not create that outcome by itself.
Pick a workflow, user group, or integration with a clear owner and a measurable result. Keep adjacent systems outside the first release unless they must change for it to work.
Record the rules, outputs, exception cases, data counts, and approval paths people depend on. Add tests or repeatable comparisons before changing the implementation.
Test functional behaviour, performance, security, resilience, integrations, and recovery. Where practical, compare old and new outputs with a bounded group before moving more work.
Name the go or no-go owner, rollback triggers, support coverage, communications, and data reconciliation steps. Decommission the old path only after expected use and hidden dependencies are accounted for.
Before funding the work
A useful approval memo makes the tradeoffs visible. It should let a business, finance, security, and delivery stakeholder see what will change and what will remain true.
State the baseline, intended result, users, in-scope workflow, excluded systems, and the decision owner.
Record the chosen path, rejected alternatives, delivery cost, licensing, infrastructure, support, and change-management assumptions.
Define data handling, access, validation, cutover, rollback, recovery, support, and eventual decommissioning responsibilities.
Primary guidance reviewed September 21, 2026. The sources support inventory, explicit migration choices, incremental delivery, testing, recovery, and secure retirement.
Bring the current system
RSC can help determine what to keep, what to change, and how to deliver the first useful modernization step without inventing a larger project than the business needs.