A Melbourne wealth management firm ran its entire client operation on a Microsoft Access database. A former employee had built it years earlier. When they left, the database stayed, but the understanding of how it worked left with them. Ten to fifteen advisers depended on a system that nobody fully understood and only one person could change.
Problem
The Microsoft Access database was a single point of failure. It lived on one machine. There was no real backup strategy and no documentation. The reporting queries had been written by hand over many years, and the business logic inside them had become the firm's operational memory. If the file became corrupted, or the one remaining person who understood it left, the practice would lose how it actually ran.
Day to day, the advisers were drowning in admin. The same client information had to be typed into several places by hand. Every new client meant the same details entered again and again across the database, the platform, and the spreadsheets that filled the gaps. Advisers spent more time on data entry than on advice. That is backwards for a wealth practice, where adviser time is the product.
Previous approaches
They evaluated Salesforce Financial Services Cloud. For a firm with ten to fifteen advisers, it was too expensive and too complex. The licensing alone was hard to justify, and the implementation needed a dedicated admin the firm did not have. Salesforce is excellent for large practices with a full operations team. For this firm, the overhead outweighed the features.
They tried to stitch their tools together with Zapier. The automations were fragile and broke regularly. Every break left a gap in the data that took hours to find and fix, and nobody could fully trust what was in the system afterwards.
They hired more admin staff. That bought some breathing room on volume, but it did not fix the cause. The data was still scattered, still entered by hand, still inconsistent across places. More people moving data between systems is not the same as the systems talking to each other.
Solution
We started with the Access database itself, because that was where the firm's real business logic lived. We reverse-engineered the schema and the queries to recover the rules the firm actually ran on, not the rules anyone could describe from memory. Years of institutional knowledge were encoded in that structure, and recovering it was most of the work.
We then designed a normalised PostgreSQL database as the foundation. The data model came first. Once the model was right, it preserved the business logic while making it documented, maintainable, and safe to change. The single point of failure became a system the whole firm could understand and use.
On top of that foundation we built an automation layer that replaced about 80 percent of the manual data entry. Client details entered once flowed wherever they were needed instead of being retyped. We built interfaces that advisers could use without training, shaped around how they actually work rather than around the database underneath.
Outcome
Manual data entry dropped by 80 percent. Advisers got hours back every week, and those hours went to client work. Client data was centralised, backed up, and accessible from anywhere instead of being locked to one machine. The firm increased client capacity without adding headcount, because the system absorbed the administrative load that used to need another hire.