How Do You Get a Legacy System Modernization Proposal from a Web Software Company?

Can a reliable proposal be made without reviewing the system?

A proposal prepared without reviewing the existing system in detail can only be an initial estimate; a reliable project proposal requires visibility into the technical boundaries of the live system. Source-code access, frameworks and libraries, database structure, hosting environment, user roles, integrations, and critical workflows directly affect the modernization scope. Technical discovery is the first delivery stage that identifies which components may be retained, which should be rebuilt, and which areas still cannot be defined with certainty.

Separate an initial estimate from a scoped proposal

During the first discussion, a company may provide a general budget framework or delivery model, but it should explain how system assessment will be performed before committing to scope. The approach to managing a project with a web software agency helps separate discovery, development, and acceptance stages before the proposal is finalized. For the buyer, the important point is not to hide unknown work inside arbitrary contingency, but to make assumptions and uncertainties visible.

• Determine access to the source code and version history.
• Review the age and support status of technologies and dependencies.
• Identify critical user roles and business workflows.
• List database, file-storage, and integration points.
• Document acceptable downtime and operational priorities.

To me, legacy code is simply code without tests. - Michael C. Feathers

What technical information should be prepared before proposals?

Information prepared before the proposal stage helps a provider understand the system faster and reduces the risk of different vendors making different assumptions about the same scope. The programming language and framework, server architecture, database engine, user counts, core roles, daily critical transactions, external service connections, and known issues should be consolidated as much as possible. If documentation is incomplete, that should be stated explicitly; missing information is itself an input to technical discovery. The provider can then determine whether additional investigation is required.

Share operational problems together with the technical inventory

A technology list alone is not enough. The buyer should also explain which screens are slow, which processes require manual intervention, which integrations fail frequently, which reports are considered unreliable, and which requested improvements the current team cannot deliver safely. A prioritized problem list helps determine whether the modernization effort is primarily technical debt reduction, capacity improvement, user-experience enhancement, or a broader rebuild.

• List the technology stack and important package versions.
• Describe database size and the main data domains.
• Identify user roles and authorization differences.
• Define daily critical transactions and operational dependencies.
• Record integrations and the owners of external services.
• Prioritize known problems by business impact.

How do you choose between rebuilding and phased modernization?

The choice between rebuilding and phased modernization should not be based only on the age of the existing code. Testability, modularity, data dependencies, integration density, critical business rules, and the cost of making changes should be evaluated together. In some systems, retaining stable modules while modernizing problematic areas may provide a more controlled path; in others, the existing architecture may no longer support new requirements and a broader rebuild may be justified. The modernization strategy should be a reasoned outcome of the technical assessment.

Make the decision at module and dependency level

Ask the provider to evaluate the system by module rather than labeling the entire application as “old” or “in need of a rewrite.” The guide to planning the custom software development process offers a useful framework for separating requirements, architecture, development, testing, and production rollout. Once retained modules, temporary bridges, and rebuilt components are identified, the proposal becomes easier to understand and compare.

• Evaluate the business criticality and change frequency of each module.
• Mark areas without adequate test coverage as separate risks.
• Identify tightly coupled components and shared data dependencies.
• List components that can be retained with clear reasons.
• Estimate temporary integration needs during phased migration.

Should data migration and cleanup be separate proposal items?

Data migration and data cleanup should appear as separate scope items because they are not the same activity. Migration covers moving records from the old structure into the new schema, field mapping, relationship integrity, and validation checks, while cleanup requires business decisions about duplicate, incomplete, invalid, or obsolete records. The quality and consistency of historical data can affect effort as much as its volume. The data transition scope should clearly state which tables will move and which records require transformation rules.

Evaluate migration cost together with data quality

If new software development and data transition are hidden under one line item, it becomes difficult to understand why proposals differ. The article on what determines custom software development cost explains the broader impact of scope, integrations, and technical complexity on pricing. When a provider can define transformation rules against sample data and explain how post-migration validation will work, this part of the proposal becomes more measurable.

• Define which data sets will migrate and which will be excluded.
• Create mapping rules between old and new fields.
• Make business decisions for duplicate and incomplete records.
• Plan a trial migration and result validation.
• Define how changing data will be handled during cutover.
• Show data-cleanup effort separately from technical migration work.

How does rebuilding integrations affect modernization cost?

The cost of rebuilding integrations depends less on the number of connections than on each integration's protocol, data flow, error handling, security requirements, and whether the connected system must also change. If the legacy application relies on direct database access, file exchange, or undocumented services, those connections may need to be redesigned in the target architecture. ERP, CRM, payment, identity, or industry-specific services may also provide different testing environments and access methods. An integration inventory should therefore be a separate technical input to the proposal.

Ask about ownership and testing conditions for every connection

When evaluating integration scope, a line that simply says “API integration” is not sufficient. The guide to planning enterprise software integration with ERP and CRM shows why data ownership and system boundaries should be defined in advance. Ask the provider to state the source system, target system, data direction, authentication method, failure scenario, test access, and responsible owner for every integration.

• List all current integrations according to business purpose.
• Review undocumented connections separately during discovery.
• Identify new API or adapter requirements.
• Clarify responsibilities of teams that own connected systems.
• Verify testing environments and sample-data access.
• Include error handling, retries, and traceability in the proposal.

How should modernization proceed while the live system runs?

If the live system must continue operating, the transition should not be treated as a single release event. Data synchronization between old and new systems, staged migration of user groups, temporary parallel operation of selected modules, and a rollback scenario for critical failure may all need to be planned. It is especially important to define when the old system will stop accepting new writes and how transactions created during the transition will be handled. The transition plan should show both the technical steps and the sequence in which business teams are affected.

Define downtime tolerance and rollback thresholds in advance

If the organization has low tolerance for downtime, the provider should break migration and release activities into an appropriate sequence. Parallel operation is not required for every project, but when it is needed the method for reconciling differences between two systems should be defined. A rollback plan also means more than turning the old server back on. The team must define how database changes, new transactions, files, and integration messages will be returned to a consistent point.

• Define the final data synchronization step before cutover.
• Evaluate phased transition by user group or module.
• Define data ownership clearly if systems run in parallel.
• Plan the downtime window and operational communication.
• Define rollback triggers and the authorized decision maker.
• Validate critical workflows immediately after transition.

How should uncertain work and assumptions appear in proposals?

Even after technical discovery, some areas may remain uncertain; a reliable proposal should show those uncertainties rather than hide them. An inaccessible third-party system, missing source code, undocumented business rule, or unclean historical data can be recorded as an assumption. For every uncertainty, the proposal should define under what condition the price or schedule may need to be reviewed. An assumption register makes issues that could otherwise create later scope disputes visible before the agreement is signed.

Connect discovery findings to change management

Instead of pricing every unknown item with a large generic risk buffer, the provider should explain which additional investigation will clarify the scope. Legacy systems may contain production behavior that no one has formally documented. If that behavior must be preserved, it should become an acceptance criterion in the new system. The proposal process should also define how newly discovered requirements will be approved, how their cost impact will be presented, and who has authority to make the decision.

• Record inaccessible systems and missing documents as assumptions.
• Turn uncertain business rules into validation questions.
• Define the approval process for change requests.
• State how the cost impact of new findings will be presented.
• List work that is explicitly excluded from scope.

Which documents should technical discovery deliver?

Technical discovery should produce more than meeting notes; it should deliver concrete documents that explain the reasoning behind the modernization proposal. At minimum, the current-state summary, system components, data and integration inventory, critical risks, proposed target architecture, transition approach, testing scope, and open assumptions should be visible. These documents explain why the proposal is divided into particular work packages. A discovery deliverable should allow the buyer to determine whether different vendors are truly pricing the same problem at the same level of scope.

Link proposal items directly to discovery documents

Technical documentation does not need to consist only of detailed architecture drawings for developers; it should also be understandable enough for decision-makers to evaluate risk and scope. Each major proposal item should, where possible, trace back to a discovery finding. Data cleanup can be linked to an identified quality issue, integration redevelopment to a current connection constraint, and parallel operation to the organization's downtime tolerance, making the commercial proposal easier to justify.

• Current-state and technical-debt summary.
• Application, database, and integration inventory.
• Proposed target architecture and modernization approach.
• Data migration and testing strategy.
• Transition, rollback, and operational risks.
• Assumptions, exclusions, and open-decision register.

How should maintenance handover be included in the proposal?

Maintenance handover should not be left as an undefined support topic that begins after the project ends; it should be part of the delivery and ownership plan in the modernization proposal. The source-code repository, environment configurations, deployment method, database backup procedure, third-party accounts, technical documentation, and monitoring access should all have defined owners. If another team may maintain the new system later, the knowledge-transfer format and acceptance process should also be specified. Maintenance handover helps ensure that the software is delivered to the organization in a sustainable form.

Separate warranty, maintenance, and new development

Defect correction, operational support, version updates, and new feature development are different services. The proposal should state which classes of defects are covered, how production incidents are reported, and how new requests will be scoped. The article on how web software agencies determine prices and costs helps place maintenance and support components alongside development when evaluating total service scope.

• Define ownership of the source code and repository.
• Document transfer of server and deployment access.
• List required technical documentation deliverables.
• Separate defect support from new development requests.
• Define monitoring, backup, and incident-response ownership.
• Specify knowledge-transfer scope if another team may take over.

How should legacy system modernization proposals be compared?

Legacy system modernization proposals should not be compared only by total price or the technology that will be used. Two proposals that appear to cover the same project may differ significantly in data migration, integration redevelopment, testing, continuity planning, uncertainty management, and maintenance handover. Buyers should therefore divide proposals into common work packages and review deliverables, acceptance criteria, responsible parties, and exclusions for each item. A comparable proposal explains not only the price but also which risk is managed by which method.

Ask every provider to quote from the same discovery questions

Giving different information to each vendor makes proposals difficult to compare. The criteria for choosing a software company and comparing proposals help evaluate technical capability and commercial scope within the same framework. When current-system documentation, priority problems, integration lists, downtime expectations, and data requirements are shared consistently with all candidates, it becomes easier to obtain reasoned project proposals instead of assumption-driven prices.

• Compare proposals under common work packages.
• Review data, integration, and transition scope separately.
• Compare assumptions and explicit exclusions side by side.
• Review acceptance criteria and delivery documents.
• Evaluate maintenance, support, and handover responsibilities.
• Ask how technical discovery findings affected pricing.