An audit of what it actually does
A written account of every function the old system performs, including the undocumented ones that exist only in one person's habits.
Web apps
Replace the system nobody wants to touch
The workbook, database or in-house tool that quietly became the thing a whole department runs on, and that everyone is now slightly afraid of. We replace it while the business keeps running on it.
Who this is for
For businesses whose old system still does something important and cannot simply be switched off. It is the wrong service if the plan is to keep that system exactly as it is and give it a newer-looking front end.
What you get
What we deliver
A data model and a migration plan
How old records map to new ones, what gets cleaned, what gets archived read-only, and what is deliberately not carried across.
The replacement, in slices
Each part goes live on its own while the rest of the old system keeps working, rather than one switch-over weekend that has to go perfectly.
A parallel-run period
Old and new handling the same work side by side, so any difference in output shows up while the old system is still there to fall back to.
A read-only archive
Historical data kept searchable and exportable for as long as your records need to be retained, without keeping the old software alive just to read it.
A rollback plan, written before the cutover
What triggers it, who makes the call, how long it takes to go back, and what happens to anything entered in the meantime.
What legacy usually means in a Manila office
Legacy here is often not an old enterprise platform. It is an Excel workbook full of macros, an Access database on one PC in accounting, or a PHP system written by someone who left years ago, kept alive because it prints a form the business still needs. That makes this a records problem as much as a code problem, because the BIR expects your books and supporting documents to stay readable and retrievable long after the transaction, and switching off the old machine is not an answer to that. Whatever personal data you carry across, or deliberately do not, needs a lawful basis and a trail under the Data Privacy Act, including the disposal. And when the team also supports overseas clients, the safe cutover window is usually a shift change rather than a weekend, with a fallback ready for the power interruption that tends to land in the middle of it.
Questions
What people ask before they buy this
Can the old system keep running while you build the new one?
That is the usual approach and the reason this work takes the shape it does. We replace it in slices and run old and new on the same work for a period, so differences surface while the old system is still available to fall back to. A single cutover is only sensible when the system is small enough that going back is genuinely easy.
Ours is an Excel workbook and an Access database. Is that too small to bother with?
No, and it is a common version of this problem in Philippine offices. The risk is rarely the technology: it is that the file lives on one machine, one person understands the macros, and nobody can tell who changed what or when. A replacement fixes those three things first, before it adds anything new.
What happens to years of old records?
They are migrated where the new system needs them and archived read-only where it does not, kept searchable and exportable either way. Your retention obligations do not end when the software is retired, so the archive has to outlive the application it came from. The goal is to switch off the old system without losing the ability to answer a question about a transaction from years ago.
Do we need to do anything about data privacy when we migrate?
If the old system holds personal data then the Data Privacy Act covers the migration itself, and the disposal of whatever you choose not to carry over. In practice that means a documented lawful basis, access restricted during the move, and a log of what moved and what was destroyed. Your data protection officer sets the rules and we build to them.
Nobody here knows how the old system works any more. Is that a problem?
That is the usual starting point, and dealing with it is the first phase of the work. We read the code and the database, watch people use it, and write the behaviour down, including the rules that exist only because someone typed them once years ago. Anything we cannot explain gets flagged for a decision instead of being quietly reimplemented a different way.
Web apps
Related services
Ready when you are
Tell us what you are building and we will tell you honestly how we would approach it.