You got a new user interface. Be careful how you throw around the term modernization. You thought a new user interface was all you needed. You forgot about the DB (database). The demands of a modern application may exceed the capabilities of your DB
To make what I’m about to suggest relevant let me share some coding practices from the past
There was a time when we described files in programs. It was possible to describe a field as numeric in one program and character in another. Then we started using externally described files and it improved the quality of the data a lot.
Since the introduction of externally described files, there have been many improvements. They focus on data quality and the programming effort required to achieve optimum results.
Before event trigger programs: An ironclad method of vetting every record/row added or updated in a file/table. (No more wondering about how those orphaned records got there) Business logic is associated with the add/ change/ delete function. Data quality is checked at the point of entry. Not even DFU or SQL can get around this.
After event triggers: can keep data up to date in real-time. Traditional end-of-day, week, month, and year processing can be performed as a result of successfully adding, updating, or deleting a record/row.
Constraints: save a lot of programming because they enforce the data relationships and prevent orphaned records. You let the DB management system check the constraints you define. You could continue to perform this check in the programs or simply let the operating system do it.
I/O (input/output) servers: are border control points for Security & rollback considerations. They simplify the administration of security and data usage.
AO Foundation (my solution) can assist you by generating programs that support these modern concepts
By doing the UI first, you are increasing the technical debt because you will be forced to convert the business logic and the constraints to the language of the new UI and or use an API. An API is a repackaging of the existing business logic, which means both versions of the business rules will need to be maintained when requirements change.
Side effects of renovating the database first.: Easier to replace the user interface.
Consolidation of the business rules in trigger programs improves agility, thus making it a more strategic solution while minimizing API requirements. Not to mention the cost associated with maintaining several versions of the business rules.
If this makes sense to you I’m suggesting you take advantage of this special offer