From Spreadsheets to Systems: A Realistic Migration Path

I once met with a company where a single Excel file generated £40 million in annual revenue. That file was nine years old, had 23 tabs, had edited by 14 different people, and had formulas that nobody understood anymore. When I asked what would happen if it broke, the finance director literally paled. When I asked if it had a backup, they said "it's on the network server, so yes?" That's not a backup strategy. That's a disaster waiting to happen.

This is the spreadsheet problem at scale: critical business operations held together with formulas and hope. Across my 120+ projects, spreadsheets are the most common source of operational risk I see. And here's the thing: the companies that succeed at moving away from spreadsheets don't do a big bang migration. They do a phased transition that keeps the business running while building proper systems underneath.

This post is about how to actually migrate from spreadsheets to systems without breaking your business.

Why Spreadsheets Are Everywhere (And Why That's a Problem)

Spreadsheets are remarkable tools. They're flexible, they're accessible, they're fast to build, and they don't require IT. Someone needs to track something, they build a spreadsheet. For small volumes and simple logic, this works fine.

But spreadsheets become dangerous when they become essential. They become dangerous when critical business decisions depend on them. And they become catastrophic when they're holding together cross-functional workflows.

Here's why spreadsheets fail at scale:

Single point of failure. The file lives on one person's computer, or in shared drive, but one person understands it. If that person leaves, or if the file corrupts, you have a serious problem. I worked with a recruitment firm where their entire candidate tracking was in a spreadsheet. The person who built it left. Nobody else understood the formula logic. They spent £8,000 rebuilding it in a proper system after she departed.

Lack of version control. Six people edit the same spreadsheet. Person A saves a version with their changes. Person B saves a different version. Suddenly you have no idea which version is the source of truth. One manufacturing client I worked with had eight different versions of their production schedule spreadsheet floating around. Production decisions were made from different versions, creating scheduling conflicts. This happened weekly.

Manual error probability. Every human-entered cell is a potential error. One client had a pricing spreadsheet where a single incorrect cell created a £40,000 pricing error on a customer quote. They didn't catch it until after the invoice was paid. The customer was generous about it, but they moved suppliers.

Scaling constraints. Spreadsheets slow down with large datasets. One financial services firm had a portfolio analysis spreadsheet that took 23 minutes to recalculate each morning. That's 23 minutes of waiting before any analysis could happen. A proper database did the same analysis in 8 seconds.

Audit and compliance problems. Spreadsheets don't have version history, access controls, or audit logs. If you're in a regulated industry, a spreadsheet-based process is a compliance problem. I had a legal services firm forced to rebuild their matter tracking in a proper system because their regulatory body wouldn't accept spreadsheet-based workflow documentation.

Integration impossibility. You can't automate off a spreadsheet effectively. A spreadsheet doesn't talk to your CRM. It doesn't update your accounting system. It doesn't trigger notifications. It's a terminal point for data. Once data enters a spreadsheet, it's stuck there until someone manually transfers it elsewhere.

The Spreadsheet Migration Framework

If you're running your business on spreadsheets, you can't just flip a switch and move everything to a system. That approach fails because:

1. The business can't stop operating during migration.

2. Spreadsheets usually exist because the proper system is either missing or insufficient.

3. The spreadsheet contains tribal knowledge that needs to be documented first.

4. People are comfortable with the spreadsheet and resistant to change.

The approach that works is a phased migration where you build proper systems alongside the spreadsheet, gradually shifting work over, and only decommission the spreadsheet once the new system is proven.

Phase 1: Audit and document the spreadsheet (weeks 1-3)

Before you can replace a spreadsheet, you need to understand it completely. What does it do? What formulas drive it? Who uses it and how? What decisions depend on it?

Create a document that describes: the spreadsheet's purpose, the inputs (where data comes from), the processing logic (what calculations happen), and the outputs (what the spreadsheet produces). Walk through a few examples with the person using it. Get them to explain their process.

This documentation is critical because it becomes your specification for the new system. One client had a revenue recognition spreadsheet that was 50% correct logic and 50% workarounds for a system that we retired. The audit revealed the workarounds, and the new system didn't need them.

Phase 2: Define the system requirements (weeks 2-4, overlapping with Phase 1)

Based on your audit, define what the replacement system needs to do. Not what the spreadsheet does: what the business actually needs to happen. Sometimes that's different.

Write requirements in plain language: "The system should accept order data in real time and automatically update inventory." Not "The system should have a spreadsheet import function." The first is a requirement. The second is a solution.

One professional services firm audited their project costing spreadsheet and discovered it was doing project costing in a way that their project management system could actually do automatically. They didn't need a new system: they needed to use their existing system better. That saved them £0 in new tool cost and £15,000 in migration cost.

Phase 3: Find or build the system (weeks 4-10)

Do you need to buy something? Can you use something you already have? Do you need to build something custom?

The options:

Use existing systems. Many businesses buy a system and don't use all its capabilities. A CRM have built-in sales forecasting, but someone's built a spreadsheet to do forecasting because they don't know the CRM can do it. Audit what you have first.

Buy a commercial system. Off-the-shelf software designed for this exact problem. Inventory management, project management, expense management, whatever. Cost: £100-1,000 per month typically. Time to implement: 4-8 weeks.

Configure a platform. Something like Airtable, Zapier, or a low-code platform that you configure for your specific needs. Cost: £50-500 per month. Time to implement: 2-6 weeks.

Build custom software. If nothing off-the-shelf works, or if your requirements are unique. Cost: £5,000-50,000+. Time to implement: 8-16 weeks.

One client needed to migrate a complex financial modelling spreadsheet. There was no off-the-shelf system for their specific use case. So they built a custom system. Cost: £18,000. Implementation: 12 weeks. But the system was 50x faster and eliminated all manual error risk.

Phase 4: Parallel running (weeks 10-18)

This is critical. You run the spreadsheet and the new system in parallel for 4-8 weeks. Every transaction goes into both. Every report is generated from both. You compare outputs obsessively. Are they the same? Where do they differ?

Parallel running is tedious and feels inefficient. It's the opposite of efficient. But it's the difference between a safe migration and a risky one.

One client wanted to skip parallel running to "save time." They migrated their entire customer database to a new system. Two days later, they discovered that 3% of customer records didn't migrate correctly. They went back to the spreadsheet while fixing the migration. Would have caught the problem in day one of parallel running.

During parallel running, you're also training people. They're using the new system while still using the spreadsheet. They're getting comfortable. They're learning.

Phase 5: Cutover and decommissioning (weeks 18-20)

Once parallel running is proven, you cut over. New data goes only into the system. The spreadsheet is archived (not deleted: archived). Old data stays in the spreadsheet for historical reference if needed.

Some companies keep the spreadsheet running read-only for another month, just in case there's a need to reference it. Then they archive it completely.

The entire process: 4-5 months from audit to cutover. That feels long until you compare it to the cost of getting migration wrong.

Real Migration Example

Let me walk through a real migration I worked on. Financial services firm, £50M portfolio value, portfolio management tracked in a spreadsheet.

Situation: The spreadsheet had 15 tabs, tracked 200+ individual positions, calculated tax efficiency, reported to clients. It had been built eight years ago. The person who built it was still there but wanted to retire in two years, and they were the only person who fully understood it. The spreadsheet was recalculated nightly and took 45 minutes. Client reports took another 2 hours of manual assembly each month.

Phase 1 audit (2 weeks): We documented the spreadsheet completely. Discovered that 30% of the logic was actually redundant: it duplicated calculations that their portfolio accounting system already did. Discovered that the data flow was inefficient: they were manually exporting from the accounting system, importing to the spreadsheet, then manually exporting reports. The spreadsheet itself wasn't the problem. The disconnected workflow was.

Phase 2 requirements (2 weeks): Requirements included: real-time data flow from accounting system to portfolio analysis, automated client reporting, faster recalculation, access control so multiple people could review (not just one person), and version history for audit purposes.

Phase 3 system selection (4 weeks): They evaluated off-the-shelf portfolio management systems (expensive, overkill), evaluated low-code platforms like Airtable (insufficient for complex financial calculations), and decided on a custom system built on their existing accounting system's API. Cost: £12,000 for the build.

Phase 4 parallel running (6 weeks): Both systems ran in parallel. Portfolio data flowed to both the spreadsheet and the new system. Reports we generated from both. The person who built the original spreadsheet reviewed them side-by-side. They found and fixed three calculation bugs in their original spreadsheet that the parallel comparison revealed. If they'd migrated without this, they would have discovered the bugs after going live.

Phase 5 cutover (2 weeks): New data went only to the system. The spreadsheet was archived. Client reporting moved to the new system. Recalculation time dropped from 45 minutes nightly to 3 minutes. Client reporting moved from 2 hours manual work per month to 5 minutes automated. The person who built the spreadsheet was able to focus on portfolio strategy instead of spreadsheet maintenance.

Total timeline: 16 weeks. Cost: £12,000. Payback: 3-4 months in labour savings alone.

Common Mistakes in Spreadsheet Migration

Trying to migrate too fast. The rush-and-migrate approach fails regularly. You don't have time to test properly. You don't have time for parallel running. Something breaks in live operations. You don't have a rollback plan. Don't do this.

Not involving the spreadsheet owner. The person who built the spreadsheet and uses it daily knows things that aren't documented. If you migrate without their involvement, you'll miss something. I worked with a team that migrated a compensation spreadsheet without involving the HR person who built it. The formula for calculating bonus structure wasn't perfectly replicated in the new system. It took six weeks to fix.

Oversimplifying the requirements. "Let's just replicate the spreadsheet in a proper system." Bad idea. The spreadsheet is what you have to work with, not what you should have. Use the migration as an opportunity to redesign the process. Make it better. Make it more efficient. A client was migrating expense tracking. Instead of replicating the spreadsheet exactly, they simplified the approval rules, automated categorisation based on vendor, and cut processing time by 65%. That only happened because they used migration as redesign opportunity.

Underestimating training time. People are comfortable with the spreadsheet. Moving them to a system takes time. Budget for training, for support, for transition. One organisation underestimated this, cut training short, and had to hire temporary staff to handle the support load after cutover.

Not maintaining the spreadsheet during migration. During the 4-5 month migration, the spreadsheet is still running and still being used. It still needs maintenance. Someone still needs to fix bugs, handle edge cases, and keep it up to date. If you don't maintain it during migration, you end up with a divergence between the system and the spreadsheet that creates migration problems.

When to Build vs. Buy vs. Keep

Not every spreadsheet needs to be replaced. Sometimes the right answer is to improve the spreadsheet itself, not replace it.

Keep the spreadsheet if: It's low-risk (not essential), low-complexity (simple logic, <100 rows of data), and perfectly adequate. Some planning spreadsheets, some one-off analyses, some temporary tracking: these are fine to leave as spreadsheets.

Improve the spreadsheet if: The underlying logic and data volumes are modest, but the spreadsheet needs better access control, better audit history, or better sharing. You can move it to a shared collaborative platform like Airtable or Google Sheets with better permissions and version control. Cost: £0-500 depending on what you choose. Risk: low.

Replace the spreadsheet if: It's essential, it's complex, it has scaling problems, it's a bottleneck, it's a compliance risk, or you need to integrate it with other systems. This is the migration path I've described above.

One organisation I worked with had 23 spreadsheets. They migrated three (essential, complex), improved five (good logic but needed access control), and kept fifteen (low-risk, simple, perfectly adequate). The strategy was differentiated based on actual risk and complexity.

The Opportunity in Migration

Here's what's often missed: spreadsheet migration is an opportunity to rethink the entire workflow.

A client was migrating their client intake spreadsheet. During the migration process, they asked: "Why do we do it this way? Is there a better way?" They redesigned the intake process, simplified it by 40%, and the new system was 40% simpler to build. The migration forced the conversation that should have happened a long time ago.

Use spreadsheet migration as a redesign opportunity. Force the right people into a room. Ask: "What are we actually trying to achieve here? Is there a better way?" Half the time, you'll find significant process improvement hidden in the workflow.

The spreadsheet isn't the problem. The spreadsheet is the symptom. The problem is usually an underlying process that needs redesign or a business capability that needs automation. The migration process is how you fix both.

Frequently Asked Questions

How long does it take to implement AI automation in a small business?

Most single-process automations take 1-5 days to implement and start delivering ROI within 30-90 days. Complex multi-system integrations take 2-8 weeks. The key is starting with one well-defined process, proving the value, then expanding.

Do I need technical skills to automate business processes?

Not for most automations. Tools like Zapier, Make.com, and N8N use visual builders that require no coding. About 80% of small business automation can be done without a developer. For the remaining 20%, you need someone comfortable with APIs and basic scripting.

Where should a business start with AI implementation?

Start with a process audit. Identify tasks that are high-volume, rule-based, and time-consuming. The best first automation is one that saves measurable time within 30 days. Across 120+ projects, the highest-ROI starting points are usually customer onboarding, invoice processing, and report generation.

How do I calculate ROI on an AI investment?

Measure the hours spent on the process before automation, multiply by fully loaded hourly cost, then subtract the tool cost. Most small business automations cost £50-500/month and save 5-20 hours per week. That typically means 300-1000% ROI in year one.

Which AI tools are best for business use in 2026?

It depends on the use case. For content and communication, Claude and ChatGPT lead. For data analysis, Gemini and GPT work well with spreadsheets. For automation, Zapier, Make.com, and N8N connect AI to your existing tools. The best tool is the one your team will actually use and maintain.

Put This Into Practice

I use versions of these approaches with my clients every week. The full templates, prompts, and implementation guides, covering the edge cases and variations you will hit in practice, are available inside the AI Ops Vault. It is your AI department for $97/month.

Want a personalised implementation plan first? Book your AI Roadmap session and I will map the fastest path from where you are now to working AI automation.