When this becomes a buying problem
A long-lived Microsoft application still runs important work, but unsupported components, tightly coupled data logic, and undocumented dependencies make every change risky.
Questions to answer before scope
- What operational problem makes legacy .net and sql modernization consulting necessary now?
- Which system, workflow, users, data, environments, and downstream actions are inside the boundary?
- Which behavior or authority cannot change without explicit approval?
- What evidence will support the next decision?
- Who owns the technical, business, security, procurement, and final release decisions?
- What is expressly excluded from the first engagement?
A defensible working sequence
- Current-state application, data, integration, and dependency inventory
- Unsupported-component and maintainability risk analysis
- Characterization-test and incremental modernization planning
- Target-state boundaries, service seams, and reversible sequencing
- Deliver the named outputs: Current-state architecture map, Technical debt and unsupported-component inventory, Modernization options and sequence.
- Use the evidence to support this decision: Stabilize, incrementally modernize, replace a bounded component, or defer with known risk.
Artifacts that should remain
- Current-state architecture map
- Technical debt and unsupported-component inventory
- Modernization options and sequence
- Parity and rollback plan
- Decision and risk register
Common failure modes
- Unlimited code review
- Full rewrite by default
- Guaranteed discovery of every hidden dependency
- Production operations outside a separate scope
- Starting implementation before the decision and evidence basis are written
- Treating a framework or checklist as proof that a specific system is safe or compliant