SEDA Collection ran its orders on an existing SQL Server database. It worked, the team trusted it, and moving the data was not an option. The problem was that customers had no way to see their order status, so the team spent a lot of time answering the same question: where is my order?
The constraint
The rule was simple: do not break what already runs. No migration, no changes to how the internal team enters orders. Whatever I built had to sit next to the old system, not replace it.
Step one: a read-only portal
I built a PHP portal that reads order status directly from the existing database. Customers search their order and see where it is in real time. Because the portal only reads, there is no risk to the data the business depends on.
Step two: the same data on mobile
Once the portal worked, SEDA wanted it on phones. I built a Flutter tracking app that talks to the same backend through a small REST API, so web and mobile always show the same status.
Step three: tools for the field team
Later came a Flutter app for field delegates, backed by a Django dashboard connected to the same legacy database. Delegates work from their phones, and management gets one place to see their activity.
What I would tell anyone with an old database
- You rarely need to migrate first. A careful layer on top can deliver value in weeks, not months.
- Start read-only. It is the fastest way to earn trust, and it removes most of the risk.
- Put an API in the middle. Once there is a clean API, every new app, web or mobile, is much easier.
Old systems are not the enemy. They hold years of real business data. The job is to open that data up safely, one useful tool at a time.
