A Melbourne wealth management firm ran its entire client practice 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 nobody fully understood and only one person could change.
Problem
The Access database was a single point of failure. It lived on one machine. There was no real backup strategy and no documentation. The queries that drove the firm's reporting had been written by hand over years, and the logic inside them was the firm's operational memory. If the file corrupted, or the one remaining person who knew 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. A 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.
What they'd tried
They evaluated Salesforce Financial Services Cloud. For a firm of 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.
What we did
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 pick up.
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 everywhere 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 locked to one machine. The firm scaled its client capacity without adding headcount, because the system absorbed the administrative load that used to need another hire.