So, the inevitable has happened. The person who built your company database has left. Perhaps they retired to a shed to build model railways. Perhaps they simply vanished into the ether. Whatever the reason, they are gone. And they have left you holding the keys to a FileMaker system that runs absolutely everything.
It handles the invoicing. It manages the stock. It tracks customer complaints, generates the shipping labels, and organises the holiday rota. It is the beating digital heart of the business. And you have absolutely no idea how it works.
There is no manual. There are no helpful notes scribbled on the margins of a legal pad. You open the script workspace and find a terrifying list of instructions. One is called "Fix Invoice". Another is called "Fix Invoice 2 Final". A third is simply called "DO NOT PRESS".
It is the technological equivalent of inheriting a homemade sports car built by a man who thought wiring diagrams were for cowards. You have a vehicle that goes very fast, but you strongly suspect the brake pedal is somehow wired to the windscreen wipers. It is a mystery wrapped in a spaghetti-code enigma. The previous developer might have been a genius. They might have been a madman. Usually, in the world of custom databases, they were a potent mixture of both.
Resist the urge to poke it with a stick
Human nature dictates that when we find a mysterious machine, we press a few buttons to see what happens. Do not do this.
This system is holding your business together. It might be held together with digital string, chewing gum and blind optimism, but it works. For now. If you go into the backend and start deleting fields because they look completely useless, you will break something critical.
Suddenly, the accounts department will be entirely unable to print anything. The warehouse will dispatch left shoes to everyone who ordered a right shoe. Nobody will get paid. You will be blamed.
Keep your hands in your pockets. Step away from the keyboard.
Your survival guide
You are alone with this beast. It is large, it is undocumented, and it is prone to unpredictable bouts of slowness on a Wednesday afternoon. Here is a practical set of steps to regain control without bringing the company to its knees.
1. Secure a proper backup
Before you even breathe heavily near the server, make sure the system is backing up. Do not assume it is. Check the schedules. Verify the files are actually being saved somewhere safe. Then, make another manual backup. Store a copy on a hard drive in your desk drawer. Treat this file like a priceless vase. If you drop the live version, this backup is the only thing standing between you and a very awkward conversation with the managing director.
2. Talk to the victims
I am talking about the users. They are the only people who know how this chaotic machine operates in the real world. Ask them what they do every single day. Ask them which layouts they use.
More importantly, ask them which buttons they actively avoid. They will tell you that if you click the green box on the customer screen, the system freezes for ten minutes. Write this down. They possess the folklore of the database. It is currently your only map to navigating the minefield.
3. Map the chaos
Open the relationship graph. It will probably look like a bowl of spaghetti that has been dropped from a great height onto a whiteboard. Do not try to untangle it yet. Just look at it.
Identify the main tables. Customers, invoices, products. See how they connect. Look for the "anchor" tables that hold everything else together. You are essentially doing forensic accounting, but with data structures instead of offshore bank accounts.
Check the layouts. You will find hidden buttons. You will find fields layered on top of other fields like a digital archaeological dig. You will click on a text box and find three more hiding underneath it. Look at the field definitions. You will find calculations that span forty lines and reference tables that were deleted during a previous management regime. Document all of it.
4. Audit the scripts
You will inevitably find hundreds of scripts. Many are dead. Some were written a decade ago to solve a problem that no longer exists, like a workaround for a printer that was thrown in a skip seven years ago.
Do not delete them. If you delete a script, you will invariably find it was the load-bearing script for the entire sales pipeline. Instead, rename them. Add a prefix like "z_Archive_" so they drop to the bottom of your workspace list. Slowly, the active, useful scripts will become apparent at the top.
The danger of the "quick fix"
Within days of you taking custody of this system, users will come to you. They will complain about a minor bug. They will ask for a brand new feature. They will tell you it should only take five minutes.
They are lying.
In an undocumented system, there is no such thing as a quick fix. Changing a simple calculation in the pricing table might accidentally alter thousands of historical invoices. Adding a new portal to a heavily used layout might grind the entire server to a complete halt.
You must test absolutely everything. Set up a separate development environment. Do not, under any circumstances, test your theories on the live system. That is like trying to change a fan belt while the engine is running at four thousand revs. It will end in tears, shouting, and massive financial loss.
Making a decision
Eventually, you have to decide what to do with this digital inheritance. You cannot just leave it as an undocumented mess forever. You have three choices.
Option one is to leave it alone. Close your eyes, cross your fingers, and pray it never breaks. This is a terrible idea. It will break. It will sit there, quietly rotting from the inside, until a completely unrelated server update tips it over the edge. And it will usually happen at four o'clock on a Friday afternoon when payroll is due and the server room is suspiciously warm.
Option two is to rebuild it from scratch. Burn the whole thing to the ground, salt the earth, and start again. This sounds very appealing. It is clean. It is pure. But it is also vastly expensive, massively disruptive, and takes an eternity.
Option three is to slowly tame the beast. Document what you find. Refactor the truly horrific code. Standardise the naming conventions. Remove the dead weight one careful piece at a time. It is not glamorous work. It is remarkably similar to weeding a massive, overgrown garden in the pouring rain. But it is usually the most sensible, pragmatic approach.
When to call for backup
There is no shame in admitting defeat. Some systems are just too far gone for one person to salvage in between their actual day job. You need someone who looks at terrible databases for a living. Someone who is no longer capable of feeling fear when opening a script workspace.
At Celsius Software, we build AI automation and search-optimised websites. We also build and rescue FileMaker systems. We have seen it all. We have seen databases held together by nothing more than a recursive script and a prayer. We are rarely surprised by the horrors lurking beneath the bonnet.
If you have inherited a system that genuinely scares you, we can help. We will audit it. We will document it. We will fix it. Or, if necessary, we will tell you honestly if it needs putting out of its misery.
Get in touch. We will put the kettle on and have a look.