# Planning a Legacy Business System Modernisation Project > How do you modernise an established application without losing business rules? Inventory behaviour, define migration checks and plan recoverable releases. Canonical page: https://webvelopment.co.za/insights/development/legacy-business-system-modernisation/ Language: en Engineering and delivery How do you modernise an established application without losing business rules? Inventory behaviour, define migration checks and plan recoverable releases. Webvelopment · 25 October 2026 ## Preserve the business behaviour worth keeping An established application can be frustrating to use and still contain rules your business needs. Before choosing a replacement, work through the tasks people perform, the records they rely on and the exceptions they handle. A slow approval screen may need replacing; the approval rule behind it may still be correct. For example, suppose a historical record type follows an unusual approval exception. Ask someone who uses that exception to demonstrate it with a suitable sample record. Note what starts the process, who can approve it, what changes on the record and how it appears in a report afterwards. Those details give the team something specific to check in the replacement. A demonstration of the common approval path would leave this risk unanswered. We would use these examples to distinguish behaviour you want to preserve from workarounds you want to retire. If the business wants to change a rule, make that choice explicit so the team can test the intended new behaviour. ## Inventory dependencies and ownership List integrations, scheduled work, reports, access roles and operational accounts. For each, identify who uses it, who can explain it and who can confirm that it works after the change. Include work that happens outside the main interface: a scheduled report or integration can matter even when nobody opens the old application to run it. A database schema shows how records are organised, but may leave their history unexplained. Keep documented rules, observed behaviour and unanswered questions separate. If a report depends on an unexplained record status, for example, trace a sample through the current process before deciding how to migrate it. Resolve questions that could change the migration approach, cost or ability to keep working before committing to a full implementation estimate. ## Choose a change boundary A phased replacement changes less behaviour in each release, while requiring old and new systems to work together temporarily. Be precise about where staff may create or edit each kind of record, how updates reach the other system and who responds when an update fails. Staff need to know which screen to use without having to understand the migration architecture. A direct cutover brings a different set of checks: data conversion, access, integrations, downtime and recovery. Compare both approaches against the work the business must continue doing. Include a reversal rehearsal in that comparison: what would the team restore, and what would happen to records entered after the switch? The answer affects whether a proposed recovery plan is practical. ## Reconcile data and behaviour Agree which totals, record samples and business scenarios must match after migration. Include rejected records, exceptional states and historical reports. Matching row counts are a useful check, but they do not tell you whether a record belongs to the right account or whether a calculation still produces the right result. Return to the historical approval example. Check that the migrated record retains its status and relationships, that the intended user can take the next permitted action, and that the result appears correctly in the relevant report. If the record should be rejected, check that outcome too. This connects the data checks to the work people actually need to complete. Before release, agree who reviews these results, how long they have and which failures would stop the release or trigger a rollback. Make monitoring and support responsibilities explicit after launch. Leave the team with the checks, their results, unresolved issues and recovery steps so the next decision does not depend on someone’s memory. ## Apply this to your project If you are preparing a modernisation brief, start with one everyday workflow, one awkward exception and the reports or integrations they depend on. Bring those examples when you [discuss your implementation question](https://webvelopment.co.za/contact/); they help us identify what needs investigation before proposing the work. Explore our [digital transformation](https://webvelopment.co.za/solutions/digital-transformation/) service and the related [anonymised project account](https://webvelopment.co.za/work/website-infrastructure-modernisation/) for further context. Planning guidance from Webvelopment Editorial. Confirm platform requirements and project assumptions before committing budget. Keep exploring ## Keep the right things connected. [Connected solutions ### Digital transformation, one workable process at a time Replace disconnected manual work with a prioritised digital roadmap, tested workflows and software that fits the way your business operates.](https://webvelopment.co.za/solutions/digital-transformation/)[Anonymised case study ### Modernising Website Infrastructure for Performance and Reliability A confidential CMS modernisation engagement addressing dependency overhead, infrastructure, CDN delivery, structured data and technical validation.](https://webvelopment.co.za/work/website-infrastructure-modernisation/) Let’s move things forward ## Start a conversation Tell us what you are working towards. We’ll help you find a practical next step. [Discuss This Planning Question](https://webvelopment.co.za/contact/)