Rebuilding a Business Application: Start with the Workflow and Data Model

The existing application is a starting point

In a recent application modernisation discussion, Matsyaa explored how to rebuild a business tool while development continued on the existing version. The current application provided a useful reference for user workflows, but its implementation had evolved through successive additions and workarounds. That raised a practical question: which parts represented lasting business requirements, and which parts existed to support the current implementation?

The work remains ongoing. The discussions establish a direction for discovery and implementation; they do not establish a completed migration or a measured performance improvement.

Review the data model before reproducing it

Copying every existing table can carry old design decisions into the replacement. During the review, participants explained that some tables supported intermediate processing or particular features rather than serving as core business records. Each table and relationship therefore needed to be understood in context before deciding how it should appear in the new design.

A table that appears unnecessary on one screen may still support another workflow, historical reporting or an integration. The review should establish its purpose and dependencies before deciding to retain, replace or retire it.

Start with one complete business workflow

The proposed approach was to begin with a central screen, identify the data and related records it needed, and develop the supporting database, APIs and interface incrementally. This gives the team a manageable place to test its understanding of the business process before extending the design to other areas.

• Identify the records, fields and relationships needed by the selected workflow.
• Confirm where each value comes from and which system owns it.
• Separate stored business facts from calculated or temporary information.
• Agree how users view, change and validate the data.
• Compare the replacement’s behaviour with agreed business rules before expanding the scope.

Preserve familiar behaviour while reviewing the architecture

The discussions also highlighted a delivery challenge: users were becoming familiar with the existing application while a replacement was being considered. Keeping familiar interactions can help continuity, but visual similarity alone cannot establish that the new version behaves correctly. Calculations, relationships and update behaviour need explicit acceptance criteria.

Where both versions continue to evolve, teams should maintain a shared record of requirement changes. Interface development can begin with sample data, provided the team agrees the expected API responses and later verifies the screens against real integrations. A working mock-up demonstrates interaction design; it does not verify the complete workflow.

Validate the reason for changing platforms

Reported loading and maintainability concerns deserve investigation before becoming assumptions about an entire platform. For a Power Apps canvas application, that includes reviewing query delegation, data retrieval and local processing. A different technology stack still needs evidence that its design meets the workload and maintenance requirements.

The practical lesson

Use the existing application to understand the business process, then make deliberate decisions about the replacement’s structure. Validate one complete workflow, document what must remain consistent and expand from there. This is the approach we are exploring in ongoing work at Matsyaa, drawing on our enterprise technology services across business platforms and custom application development.