Does one person hold a spreadsheet your business cannot lose?
A 20-minute call. PCG asks what the spreadsheet does and who understands it, then explains how to move that knowledge into a system.
How does a personal spreadsheet become business infrastructure?
Almost no one sets out to run a department on a spreadsheet. It happens one helpful addition at a time. An analyst builds a tracker to make their own job easier. A manager asks for a tab. A second team starts sending their numbers to the same file. Two years later, the quarterly forecast, the commission run, or the production schedule depends on a workbook that grew in the dark.
By then it is infrastructure, but it was never designed as infrastructure. There is no documentation, because it was never a project. There is one author, because it was never meant to be shared. And there is a quiet assumption that the person who built it will always be around to keep it running.
How risky are the spreadsheets businesses already rely on?
More than most owners would guess, and the research on this is unusually consistent. The European Spreadsheet Risks Interest Group reports that the majority, more than 90 percent, of spreadsheets contain errors1. Field audits of real business spreadsheets have found errors across a wide span of the files examined, with the more rigorous studies landing at the higher end2.
The harder problem is psychological. People are confident in spreadsheets precisely because they do not go looking for mistakes. In controlled studies, developers estimated they had a 10 to 18 percent chance of an error, while 86 percent of them had actually made one3. The errors are not loud. They sit in a single cell, feed a total, and produce a number that looks reasonable enough to act on. A business-critical spreadsheet owned by one person is the place this risk concentrates, because no second set of eyes ever checks it.
What is the key-person risk, specifically?
Key-person risk is the exposure a business carries when one individual is the only one who understands how something essential works. With a spreadsheet, it shows up in a precise way. One person knows why column M subtracts a value that looks like it should be added. One person remembers the manual step every Friday that keeps the totals honest. One person can tell whether a strange result is a real signal or a known quirk.
While that person is at their desk, none of this looks like a problem. The spreadsheet works. The risk is invisible right up until the moment it is not, which tends to be a resignation, a long illness, a retirement, or a Tuesday when they are simply unreachable and a number is due. This is the spreadsheet version of a problem PCG sees across technologies, described in the IT key-man risk.
Why doesn't "just have someone else learn it" work?
It sounds like the obvious fix, and it rarely holds. The formulas are visible, but the formulas are not the knowledge. The knowledge is the unwritten context: why a rule exists, which inputs are trusted, what the owner quietly corrects before anyone sees the output, and which tabs are live versus abandoned.
A successor inherits the cells without the reasoning. They can keep the spreadsheet running on a good day, and they are lost the first time it behaves strangely, because the person who knew what strange meant is gone. Handing the file over is not the same as handing over the understanding, and the understanding was never written down.
What does moving off the personal spreadsheet look like?
The goal is to move the knowledge out of one head and into a system the whole team can rely on. The order matters, and the first step is the one that expires.
- Capture the owner's knowledge while they are here. Document the rules, the manual steps, and the exceptions, working with the person who knows them before that window closes.
- Turn the rules into a real design. The logic that lived in cells becomes enforced rules in a database, so it runs the same way every time.
- Rebuild it as a multi-user system. Validation at entry, a recorded history of changes, and access for more than one person, so the work no longer routes through a single desk.
- Keep the data with the business. The records belong to the business and move into a database the business controls, with backups and history, instead of a file on one laptop.
The data stays the business's own throughout. What changes is that the rules and the history stop being one person's private memory and become part of a system anyone authorized can run. The operational side of that change, from the point of view of the people doing the daily work, is covered in what changes when a spreadsheet moves to SQL Server.
What happens if you wait until the person leaves?
The spreadsheet keeps working after they go, which is exactly what makes waiting feel safe. Nothing breaks on the last day. The cost arrives later, when a number looks wrong and no one can explain the formula, or when a new requirement needs a change nobody dares to make.
At that point the job is reconstruction with the author gone, which is the same predicament as rebuilding software when the original developer has vanished, only now it is the spreadsheet the business runs on. PCG handles that version too, described in what to do when your developer disappears. It is solvable either way. It is simply cheaper, faster, and safer while the person who built it can still answer the phone.
Capture the knowledge before it walks out the door
PCG runs a fixed-fee discovery that documents how the spreadsheet works and quotes a path to a multi-user system with a fixed scope.
Frequently Asked Questions
1 European Spreadsheet Risks Interest Group (EuSpRIG), Research and Best Practice. The majority, more than 90 percent, of spreadsheets contain errors. eusprig.org
2 R. Panko, University of Hawaii, research on spreadsheet errors, summarized via EuSpRIG. Field audits of operational spreadsheets report error rates across a wide range of the files examined, with more rigorous methodologies at the higher end. eusprig.org; panko.shidler.hawaii.edu
3 R. Panko, spreadsheet error and overconfidence research. Developers estimated a 10 to 18 percent chance of error, while 86 percent of participants had made at least one. eusprig.org; panko.shidler.hawaii.edu
A 2026 joint analysis by SentinelOne and Censys scanned the public internet for 293 days and found 175,000 unique Ollama instances exposed across 130 countries, most with no authentication and no firewall protection1. Many had tool-calling capabilities enabled, meaning attackers could not just consume the host's compute resources but potentially execute commands on the underlying system.
This is the part of the implementation that gets skipped most often. Ollama works perfectly on the developer's laptop with default settings. The production deployment that survives a security audit, runs as automated failover, and is tested regularly requires the steps in this article.
Why does Ollama need a firewall?
By default, Ollama binds only to 127.0.0.1:11434, which means localhost only2. This default is safe. The Ollama API is unreachable from other machines on the network, and no firewall configuration is strictly necessary.
The default changes the moment OLLAMA_HOST is set to 0.0.0.0:11434, which is required for any deployment where Ollama needs to serve requests from other machines (the most common business use case). At that point, the API is reachable from anywhere on the network. Without authentication and without a firewall, any user on the local network or, worse, any reachable internet host, can:
Submit arbitrary inference requests that pin the GPU for minutes at a time, effectively a denial-of-service attack against the host machine.
Exfiltrate model outputs by sending crafted prompts designed to leak training data or sensitive information that was used in fine-tuning.
Map the environment by querying the API for installed models, GPU specifications, and other host details that inform a larger attack.
Critical: Ollama has no built-in authentication. If OLLAMA_HOST is set to 0.0.0.0, anyone who can reach port 11434 can use the API. Firewall rules are the primary access control.
How is the firewall configured on Linux?
Linux has two common firewall tools. Ubuntu and Debian use ufw (Uncomplicated Firewall). Red Hat, CentOS, and Fedora use firewalld. Both achieve the same result with different syntax.
ufw on Ubuntu and Debian
The pattern is straightforward: deny port 11434 by default, then allow only the specific subnet or IP addresses that should have access.
firewalld on Red Hat, CentOS, Fedora
firewalld uses zones. The pattern is to add port 11434 to an "internal" zone that includes only trusted source addresses, and explicitly close that port in the "public" zone.
How is the firewall configured on Windows?
Windows uses Windows Defender Firewall. PowerShell as Administrator is the simplest way to configure rules consistently. The goal is the same: allow port 11434 only from trusted subnets.
How is the firewall configured on macOS?
macOS uses pf (Packet Filter) for firewall rules. The application firewall in System Settings does not provide enough granularity for port-level control. Editing the pf configuration directly is required.
What additional Ollama hardening matters?
Firewall rules are the first layer. Three more environment variables and configurations reduce the attack surface further.
Restrict CORS origins
Set OLLAMA_ORIGINS to the specific frontend URLs that should be allowed to call the API from a browser. This prevents arbitrary websites from making cross-origin requests to Ollama if a user visits them while on the corporate network3.
Disable the built-in web UI in production
Ollama includes a basic web UI that exposes model metadata and lacks role-based access control. Disable it in production deployments4.
Run Ollama as an unprivileged user
The official Linux installer already creates an ollama system user with no shell access. Verify this on existing installations and avoid running Ollama as root or as the primary user account. Resource limits via systemd cgroups prevent runaway processes from affecting the rest of the system.
Production hardening checklist
- Firewall rules in place restricting port 11434 to trusted sources only
- OLLAMA_ORIGINS set to specific allowed origins, not wildcard
- OLLAMA_NO_WEBSERVER=1 set to disable the unauthenticated UI
- Ollama running as an unprivileged system user, not root
- Reverse proxy with authentication in front of Ollama if accessed across networks
- Logs being collected and reviewed (see Part 3 monitoring script)
- Disk encryption at rest for the model storage directory
How does automatic failover from cloud AI to local AI work?
The architecture is simple: a thin client library sits between the application and the AI provider. Every request goes through the client. The client tries cloud AI first, and if that fails for any reason, retries the same request against local Ollama. The application code calling the client never knows which backend served the response.
The failover client handles three cases:
Connection failure
Cloud AI endpoint is unreachable, DNS fails, or TCP connection times out. Switch to Ollama immediately.
HTTP error
Cloud AI returns 5xx status code (server error) or specific 4xx codes (rate limits, service degraded). Retry with Ollama.
Timeout
Cloud AI accepts the request but takes longer than the timeout threshold. Cancel and retry with Ollama.
A working failover client in Python
The code below is the same pattern PCG uses for production deployments. It handles all three failure modes, logs which backend served each request, and exposes a single interface that drop-in replaces direct calls to the OpenAI or Anthropic SDK.
ai_request() never knows whether the response came from cloud AI or local Ollama. The failover is transparent, which is the whole point.
What is contingency mode and when does it activate?
Contingency mode is the operational state where all AI traffic routes to local Ollama by default, skipping the cloud AI attempt entirely. This is useful in two scenarios.
Known cloud outage. If the team knows the cloud provider is down (from a status page, social media, or repeated failover events in the logs), forcing contingency mode skips the wasted attempt at calling cloud AI and reduces latency for every request during the outage.
Compliance requirements. Some workflows handle data that should never touch cloud providers. Contingency mode can be enabled selectively for these workflows while other parts of the business continue using cloud AI.
Implementation is a single environment variable that the failover client checks before making any cloud request:
How often should the failover system be tested?
Quarterly at minimum. Monthly for business-critical deployments. The test is straightforward and takes about 15 minutes.
Quarterly failover drill
- Pick a low-traffic window (early morning, weekend, post-business hours)
- Block outbound traffic to the cloud AI endpoint at the firewall level for 15 minutes
- Have team members use AI-dependent workflows normally during the block
- Verify that the failover client logged "Cloud unavailable, falling back to Ollama" for every request
- Confirm response quality from local models was acceptable for the workflows tested
- Confirm monitoring alerts fired correctly (the team got notified)
- Remove the firewall block and verify automatic recovery to cloud
- Document any failures, surprises, or workflow gaps for the next iteration
Untested failover is failover that does not work when needed. The drill exists so the team finds problems in a controlled 15-minute window, not during an actual 78-minute Anthropic outage.
Does PCG build production AI continuity systems for clients?
Phoenix Consultants Group has been building production software systems for operational continuity since 1995, and three decades of experience in environments where business-critical software cannot stop translates directly to AI infrastructure. A custom AI continuity engagement covers everything in this series as a single deliverable: hardware assessment, Ollama deployment, monitoring integration, failover client development, security hardening, and team training on the contingency procedures.
The FireFlight Data System, PCG's modular platform for operational data, uses the same engineering discipline. Continuous monitoring, automatic recovery, security defaults that assume the worst, and tested procedures for every failure mode. The Ollama deployment follows that same playbook because the goal is the same: a system that works when the team needs it most.
Need a turnkey AI continuity system?
PCG handles hardware, deployment, monitoring, failover code, security hardening, and team training as one engagement. The diagnostic call is with an engineer, not a sales tier.
Frequently Asked Questions
Does Ollama need a firewall for business use?
How do I configure a firewall for Ollama on Linux?
How does automatic failover from cloud AI to local AI work?
Should failover be automatic or manual?
What is contingency mode for an AI continuity system?
How often should the failover system be tested?
Sources
1 SentinelOne and Censys joint analysis on exposed Ollama instances, early 2026: serverman.co.uk/ai/ollama/ollama-security-guide
2 Ollama default network binding documentation: github.com/ollama/ollama/blob/main/docs/faq.md
3 Ollama environment variables reference, OLLAMA_ORIGINS for CORS control: docs.ollama.com
4 Ollama production security configuration, web UI and authentication: markaicode.com/configure-ollama-firewall-rules-security
Continue Reading
Get the full security and failover guide
This is Part 4 of a 4-part series on building an AI continuity plan with Ollama. Enter your email to unlock the rest of this article including firewall configuration for Linux, Windows, and macOS, a working Python failover client, and the testing drill that keeps the system trustworthy.
We verify your email first. One click confirms your subscription.
Developers use Claude Code to write and review code. Marketing teams draft content with ChatGPT. Operations staff process documents, summarize meetings, and answer internal questions through AI assistants embedded in daily workflows. For a growing share of businesses, AI has joined email and internet access on the list of services that, when they fail, the workday effectively pauses.
Yet most organizations have no continuity plan for AI outages. Disaster recovery exists for servers, databases, and network equipment. AI is rarely included.
How often do cloud AI services actually go down?
More often than most teams realize. OpenAI's published status data shows roughly 99 percent uptime across recent 90-day windows1. Anthropic publishes comparable numbers for Claude2. A 99 percent figure sounds reassuring until the math is applied: 99 percent uptime equals roughly 7 hours of downtime per month, or 87 hours per year.
Recent major incidents make the abstract concrete. On April 28, 2026, Claude AI suffered a major outage that took down Claude.ai, Claude Code, Claude Chat, and the Anthropic API simultaneously, with more than 12,000 users filing reports on Downdetector before service restored after roughly 78 minutes3. Just 8 days earlier, on April 20, 2026, Claude had experienced a separate partial outage affecting authentication across the same surfaces3. ChatGPT experienced a major global disruption on April 20, 2026, with thousands of simultaneous reports across the UK, US, and India, affecting both the chatbot and the Codex platform4. Earlier in the year, on February 25 and 26, 2026, OpenAI logged back-to-back incidents affecting artifact generation and ChatGPT Apps integrations5. Across the same 90-day window, monitoring services tracked 134 Claude incidents and 54 ChatGPT incidents, with median recovery times measured in hours, not minutes6.
The pattern is consistent: outages happen, they last hours, and they often hit multiple platforms simultaneously because shared infrastructure underlies them all.
What does an AI outage actually cost a business?
The visible cost is paused work. A development team that has restructured around Claude Code suddenly cannot get code review, suggestions, or refactoring assistance. A marketing team that drafts and edits with ChatGPT loses its content pipeline. Customer support teams that route initial responses through AI have to fall back to fully manual workflows.
The hidden cost is the recovery time after service restores. Teams often spend hours debugging what they assume is their own broken code or misconfigured integrations before realizing the AI provider is the actual problem.
Silent Failures
Cloud AI does not always fail loudly. Models return empty responses, time out unpredictably, or degrade quietly while teams assume their own code is broken.
Shared Infrastructure
Most cloud AI providers rely on overlapping infrastructure layers. When Cloudflare or a major datacenter fails, multiple AI services fail together.
No Tested Fallback
Disaster recovery plans cover servers and databases. AI services rarely appear on the continuity checklist, leaving teams with no documented procedure when outages happen.
What is local AI and how does it fit into a continuity plan?
A continuity plan answers a specific question: when the primary system fails, what runs instead. For cloud AI, the answer is a parallel local AI system operating on the organization's own hardware, ready to take over critical workflows during an outage.
Local AI runs entirely on the user's hardware. No data leaves the building. No internet connection is required after initial setup. The most practical local AI runtime for business use is Ollama, an open-source platform that downloads and serves large language models on the same machine where business applications are running7.
Once installed, Ollama exposes an HTTP API on the local network that is compatible with the OpenAI API format. Business applications that currently call Claude or ChatGPT can be redirected to call Ollama instead with minimal code changes. The fallback is technical, automatic, and verifiable.
Does a local AI backup require special hardware?
Yes, and this is the part of the conversation that gets skipped most often. Ollama is free to install, but it is not magic. The models that make it useful for business work require specific hardware to run at usable speeds.
What hardware works
Ollama performs well on NVIDIA GPUs with Compute Capability 5.0 or higher (essentially NVIDIA GTX 960 and newer), Apple Silicon chips (M1 through M4), and AMD GPUs with ROCm 7 drivers on Linux8. On these platforms, a 7-billion-parameter model generates between 40 and 120 tokens per second depending on the specific hardware, which is fast enough for production use.
What hardware does not work
CPU-only operation is technically possible. Ollama will install and run on a machine with no GPU. The result, however, is between 3 and 8 tokens per second for the same 7B model8. That is too slow for any workflow that involves waiting for a response, which describes nearly all business use cases.
Older Intel Macs (pre-Apple Silicon) and AMD GPUs on Windows currently fall into the unsupported or poorly supported category. Organizations relying on either should plan around that reality before committing to a local AI implementation.
This series is built around organizations with appropriate hardware. CPU-only deployments are addressed honestly: not viable for production failover.
What does this series cover?
This is Part 1 of a four-part series on building an AI continuity plan using Ollama. Subsequent parts go deep on the technical implementation:
Part 2: Hardware Requirements and Installing Ollama. A detailed hardware decision guide, the exact GPU and driver specifications, step-by-step installation on macOS, Linux, and Windows, and the configuration variables that matter for production use.
Part 3: Choosing Models and Monitoring Your Local AI. Which model to assign to which business task, optimized system prompts for local models, and a complete Python monitoring script that runs as a scheduled task and alerts when Ollama goes unhealthy.
Part 4: Securing and Automating Your Failover. Firewall configuration for Linux, Windows, and macOS deployments. Auto-failover client code that detects cloud AI failures and routes requests to Ollama automatically. Full contingency mode procedures and the testing drills that keep the system trustworthy.
Does PCG build custom software systems like this for clients?
Phoenix Consultants Group has been building production software systems for operational continuity since 1995, with three decades of experience in environments where business-critical software cannot stop. The FireFlight Data System, a modular platform PCG developed and maintains, was designed with that same operational reality in mind: hosted on PCG infrastructure, monitored continuously, and architected so that one component's failure does not cascade through the rest.
The same engineering discipline applies to AI infrastructure. A custom AI continuity implementation involves hardware assessment, Ollama deployment, monitoring integration, failover client development, and team training on the contingency procedures. PCG handles all of it as a single engagement.
Building AI continuity for your team?
PCG designs and deploys custom failover systems for businesses dependent on cloud AI. The diagnostic call is with an engineer, not a sales tier.
Continue the Series
Want the technical implementation guide?
Parts 2, 3, and 4 cover hardware requirements, installation across macOS, Linux, and Windows, model selection, monitoring scripts, firewall configuration, and auto-failover integration. One installment per week, sent directly to your inbox.
We verify your email before sending anything. One click confirms your subscription.
Frequently Asked Questions
What is an AI continuity plan?
How often do cloud AI services like ChatGPT or Claude go down?
Can my business run AI locally without internet access?
What hardware does a local AI backup system require?
Is local AI a replacement for Claude or ChatGPT?
What does an AI continuity plan cost to set up?
Sources
1 OpenAI Status Page, 90-day uptime metrics: status.openai.com
2 Anthropic Status Page, 90-day uptime metrics: status.anthropic.com
3 Rolling Out, Claude AI outage hits 12,000 users in major disruption, April 28, 2026: rollingout.com/2026/04/28/anthropic-claude-outage-users-locked-out
4 Open Magazine, ChatGPT Hit by Major Global Outage, April 20, 2026: openthemagazine.com
5 StatusGator, OpenAI Outage History, February 2026 incidents: statusgator.com/services/openai/outage-history
6 IsDown monitoring data, 90-day incident counts for Claude and ChatGPT, May 2026: isdown.app/status/claude-ai
7 Ollama official documentation: ollama.com
8 Ollama GPU requirements and benchmarks, official documentation: github.com/ollama/ollama/blob/main/docs/gpu.md
Continue the Series
Get the technical implementation guide
Parts 2, 3, and 4 cover hardware requirements, installation, model selection, monitoring, firewall configuration, and auto-failover integration. One installment per week, sent directly to your inbox.
We verify your email before sending anything. One click confirms your subscription.
When the source code for business software is lost, the cost falls into four categories that compound over time: operational disruption when the system finally fails, the migration premium paid for emergency timelines, business continuity exposure during unplanned downtime, and the long-term erosion of institutional knowledge. Total financial impact depends on how long the exposure remains unaddressed.
Source code loss rarely arrives as a single event. It accumulates quietly across years of staff turnover, vendor transitions, lost backup tapes, and undocumented contractor work. By the time a CFO becomes aware of the exposure, the business is often already running production software that nobody on the current team can modify, audit, or recover from a major failure. This article presents a financial framework for evaluating that exposure before the system fails, when the cost of action is still controllable.
Phoenix Consultants Group has been recovering orphaned business software since 1995, across more than 500 production engagements covering Microsoft Access, Visual FoxPro, Visual Basic 6, Delphi, PowerBuilder, and early .NET applications.1 The categories below come from that engagement history and reflect the financial patterns CFOs encounter when source code recovery becomes urgent rather than planned. This framework is platform-agnostic, so the financial mechanics apply equally to any custom business software in production.
What does "source code is lost" actually mean for a business in 2026?
Source code loss is a spectrum, not a single condition. A CFO assessing exposure should understand which point on the spectrum applies to the business, because the financial implications differ at each point. Four scenarios recur across PCG engagements, ordered from least to most severe.
Source code exists, knowledge does not
The source files are accessible on company servers, but nobody on staff or in any active vendor relationship can productively read them. Financial exposure: moderate, recoverable through a documented application audit.
Source code exists, location is unknown
The source files were preserved somewhere by a former developer or vendor, but the current team cannot locate them. Financial exposure: elevated, requires source recovery work before assessment is possible.
Partial source code only
Some source files are recoverable but others are missing, often the most recently modified ones. Financial exposure: high, requires reconstruction of missing components alongside recovered material.
Compiled application only
Only the executable and the database remain. No source files can be located anywhere. Financial exposure: highest, requires reverse-engineering from the compiled application and the data structure.
The framework that follows applies across all four scenarios. Cost mechanics, however, scale with severity. A CFO who identifies the scenario early has significantly more options than a CFO who discovers the exposure during a production failure. Early identification preserves the planning window in which exposure can be quantified, recovery can be scoped, and budget allocation can occur on a deliberate schedule.2
What is the cost of operational disruption when the software finally fails?
The first cost category is operational disruption. Line items appear immediately and continue accruing until the business resumes normal operations. CFOs typically focus on direct staff productivity loss, which is the most visible component, but operational disruption includes several other measurable expenses that surface only after the failure begins.
Staff productivity loss is the headline figure. When the system that runs accounting, inventory, customer records, or compliance reporting becomes unavailable, the staff who depended on it cannot perform their normal work. Some shift to manual workarounds using spreadsheets and paper forms. Others wait. The cost is the fully-loaded labor expense for the affected staff during the entire disruption window, less any productive work they manage to complete through alternative means.
Customer-facing impact follows quickly when the affected software touches the customer experience. Order intake delayed by manual workarounds. Customer service responses extended because the agent cannot look up account history. Invoices delayed because the billing system is the affected platform. Each touchpoint absorbs a measurable cost in delayed revenue, customer service overhead, and reputational impact that compounds across the disruption window.
Downstream system failures are the cost category most often underestimated. Modern business software rarely operates in isolation. The affected application typically feeds data to accounting, reporting, regulatory submission, or partner integration platforms. When the source system fails, the downstream systems begin producing stale or incomplete output. The cost is the staff time required to identify, correct, and restore confidence in every downstream data flow after the source system returns.2
How does emergency-timeline migration cost compare to planned migration?
The second cost category is the emergency migration premium. A migration triggered by a production failure runs on whatever schedule the broken business can survive, against whatever vendor the business can engage on short notice, with whatever scope the business can articulate during emergency conditions. Each of those constraints translates into measurable additional cost compared to a planned migration of the same application.
Timeline compression is the largest premium driver. A planned migration spreads discovery, design, build, and cutover across a comfortable window that allows for testing, validation, and operational learning. An emergency migration compresses the same work into whatever window the business can survive without the original software. Compression typically requires additional engineering hours to maintain quality under reduced timeline, premium rates for accelerated turnaround, and additional risk reserves to handle issues that surface late in the compressed schedule.
Vendor selection power disappears when the business is in emergency mode. A planned migration allows the CFO to evaluate multiple vendor proposals, negotiate scope, and select the engagement that produces the best long-term value. An emergency migration eliminates that negotiating position. The business engages whichever qualified vendor can start immediately, at whatever rate that vendor proposes, with whatever scope the vendor is willing to commit to under the time constraint. Price differences between selected-vendor and available-vendor often exceed the difference between planned-timeline and emergency-timeline considered alone.
Scope inflation is the third driver. A planned migration begins with a documented source application inventory that defines exactly what must be replicated in the destination system. An emergency migration begins without that inventory, because the business has not had time to build it. The vendor is forced to estimate scope against incomplete information, which produces either an inflated estimate to cover unknowns or an underscoped commitment that requires expensive change orders during execution. Either outcome costs more than a planned migration with documented scope.3
The emergency premium is not a small percentage adjustment. Across PCG engagements, an emergency migration consistently costs significantly more than the same scope executed on a planned timeline, before counting the operational disruption cost incurred during the emergency window. The decision to delay assessment is the decision to pay the premium.
What is the business continuity exposure during unplanned downtime?
The third cost category is business continuity exposure during the downtime window itself. Operational disruption captures the staff and customer impact. Business continuity exposure captures the broader financial risks that surface when revenue, compliance, or regulatory obligations depend on the affected software.
Revenue at risk is the most measurable component. When the affected software is part of the revenue process, every hour of downtime carries a quantifiable opportunity cost. Manufacturing operations that cannot produce. Service businesses that cannot bill. Retail operations that cannot transact. The cost is the gross revenue normally generated during the affected window, less whatever portion the business successfully recovers through workarounds or post-recovery batch processing.
Compliance and regulatory exposure carries the highest tail risk. Industries operating under regulatory schedules, such as environmental remediation, OSHA reporting, ISO 9000 documentation, or industry-specific compliance frameworks, face penalty exposure when the supporting software fails during a reporting window. The cost includes any penalties assessed, the staff time required to demonstrate good-faith compliance during recovery, and in severe cases the cost of external counsel or regulatory negotiation.4
Audit failure is the related risk that surfaces during external review rather than regulatory deadline. A financial audit, a quality systems audit, an insurance audit, or a customer audit conducted while the affected software is unavailable produces findings that can extend significantly beyond the original audit scope. Auditors who encounter undocumented systems often expand the scope of their review to validate adjacent business processes, which carries its own cost in staff time and potential remediation findings.
What is the long-term cost of lost institutional knowledge?
The fourth cost category is institutional knowledge erosion. This category accrues continuously, not at the point of system failure, which makes it the easiest cost to underestimate in advance and the most disruptive cost to address after the fact. Three components compose institutional knowledge erosion.
Undocumented business rules are the first component. Custom business software accumulates rules over years of development: pricing calculations, approval workflows, validation logic, regulatory mappings, and workflow conditionals that reflect how the business actually operates. When the original developer leaves and the source code is lost, those rules exist only inside the compiled application. The business operates on rules nobody on staff can articulate, which means decisions that depend on those rules cannot be reviewed, updated, or audited without rebuilding the rule logic from scratch.
Training cost is the second component. New staff who join the team after the institutional knowledge is lost must learn the system entirely from its observable behavior, without access to documentation that explains why the system behaves as it does. Onboarding timelines extend accordingly. The risk of staff making decisions based on incorrect mental models of the software increases. Each new hire carries a higher onboarding cost than they would in an organization with documented systems.
Decision lag is the third component, and the one most directly measurable in CFO terms. When a business question depends on understanding what the software actually does, and nobody on staff can answer the question definitively, decisions either delay until investigation completes or proceed against incomplete information. Both outcomes carry cost. Pricing decisions made on misunderstood logic. Capacity planning based on incorrect assumptions about system limits. Compliance reporting that cannot be defended under audit because the underlying calculations cannot be explained.2
Speak directly with the engineer who would scope your exposure assessment
A free 30-minute consultation to evaluate which of the four cost categories apply to your situation. No obligation, no sales handoff.
What hidden financial risks do CFOs underestimate?
Beyond the four primary cost categories, three secondary risks recur across CFO engagements. Each one is invisible until it triggers, and each one can equal or exceed the primary cost categories in financial impact when it surfaces.
The first hidden risk is integration cascade failure. Affected software typically connects to other systems through APIs, scheduled data transfers, or shared databases. When the affected software fails, the integration connections fail with it. Each connected system then begins producing incorrect output, missing updates, or accumulating queued transactions that cannot process. The cost of restoring confidence in every downstream system after the primary failure resolves often exceeds the cost of the primary recovery itself.
The second hidden risk is vendor concentration. CFOs who have not assessed source code exposure often discover that a single former vendor or contractor was responsible for multiple business-critical applications. When one of those applications fails and recovery is needed, the same exposure profile applies to every other application that vendor built. A single recovery engagement may surface the need for parallel recoveries across the rest of the portfolio, each carrying its own cost.
The third hidden risk is talent market exposure. Pools of developers qualified to work on legacy platforms shrink every year. CFOs who plan to address source code exposure "eventually" face a continuously degrading talent market for the platforms in question. The same recovery engagement scoped today costs more next year, and significantly more in five years, simply because the developer talent capable of executing it becomes scarcer over time.1
How can a CFO quantify exposure before the system fails?
The exposure assessment is a defined engagement, not an open-ended investigation. PCG performs source code and application inventory assessments designed specifically to produce a CFO-grade financial exposure document. Each deliverable is a written report mapping operational functions to the cost categories described above, with the exposure level identified for each function.
Assessment phase work typically completes in 2 to 4 weeks for a mid-sized business application. PCG works against copies of the source code, the compiled application, and the production database. Production systems continue operating normally throughout the assessment. The deliverable stands on its own as a planning document, regardless of whether the business subsequently chooses to proceed with source recovery, migration, or continued operation under the existing application.3
Without an exposure assessment
CFO operates on assumption
- Total financial exposure unknown
- Cost categories not separated by operational function
- Vendor concentration risk undocumented
- Recovery cost can only be estimated after system failure
- Budget planning happens reactively, under timeline pressure
- Compliance and audit exposure unquantified
After the exposure assessment
CFO has a planning document
- Written exposure profile organized by business function
- Cost categories quantified for the specific application
- Vendor concentration risk mapped across the portfolio
- Recovery engagement scope and timeline documented
- Budget allocation can happen on a planned schedule
- Compliance and audit exposure included in the assessment
A planned exposure assessment costs measurably less than the operational disruption of a single production failure. CFOs who have completed the assessment own a planning document the business uses regardless of next steps.
PCG's exposure assessment connects naturally to subsequent engagements when the business chooses to proceed. Recovery work begins with the inventory already in hand. Migration scoping begins with the financial categories already documented. A continued-operation path also becomes possible because the business now has the documentation it never previously had. The assessment is the foundation, not a commitment to any particular next step.1
Quantify your source code exposure before the system fails
A free 30-minute consultation, followed by a fixed-fee exposure assessment if it is the right next step.
The system works until a Windows update, a server replacement, or a compliance audit forces the issue. By the point of failure, the CFO has no control over timeline, vendor selection, or scope. Financial exposure is highest when the business is forced to act under emergency conditions. CFOs who assess exposure before the system fails preserve the option to act on a planned schedule, which materially reduces total cost.
PCG performs a source code and application inventory engagement that produces a written assessment of what exists, what is recoverable, and what is at risk. The deliverable includes an exposure profile organized by business function, so the CFO can match financial risk to operational dependency. The engagement does not require migration commitment. The assessment stands on its own as a planning document.
The classification depends on the scope. A pure assessment and inventory engagement is typically an operational expense. A full source recovery followed by migration produces a new application asset that qualifies for capital treatment under standard accounting practice. PCG provides documentation suitable for either treatment and recommends consulting with the business accounting team on classification specific to the engagement.
A developer being unreachable means the knowledge in their head is gone, but the source code may still exist on company servers or backup media. Source code loss is more severe: the source files themselves cannot be located, and only the compiled application remains. Both situations are recoverable through PCG's discovery process, but source code loss extends the timeline and requires more reverse-engineering work to reconstruct the business logic.
The exposure assessment phase typically completes in 2 to 4 weeks for a mid-sized business application. The deliverable is a written report mapping each operational function to its associated financial risk if the supporting software fails. The assessment runs independently from any subsequent recovery or migration engagement. The CFO ends the assessment owning a planning document the business can use regardless of next steps.
1 Phoenix Consultants Group, My Developer Disappeared: What Do I Do? phxconsultants.com
2 Phoenix Consultants Group, Visual FoxPro Rescue When Your Developer Is Gone. phxconsultants.com
3 Phoenix Consultants Group, Conversion, Migration and Integration service page. phxconsultants.com
4 Phoenix Consultants Group, True Cost of Technical Debt: An Executive Guide. phxconsultants.com
This article is informational and reflects PCG's experience executing source code recoveries and orphaned system rescues since 1995. It is not legal, regulatory, financial, or accounting advice for any specific situation. CFOs should consult with their accounting team on expense classification and with legal counsel on contractual matters specific to their business. For guidance tailored to a particular source code exposure assessment, contact Phoenix Consultants Group directly.
There is a specific kind of message that stops a leader cold.“Hey, do you have a few minutes today? I’ve got some news.”You already know what comes next. Your developer, the one whose name comes up every time someone says “we should ask before touching that,” is leaving.New offer. Burnout. Career change. The reason does […]
Why does growth create chaos instead of momentum?
The pattern has a name worth knowing: architectural lag, where operational complexity outgrows the systems meant to carry it. A manual process that was fine at a million in revenue becomes a bottleneck a few times larger, and the primary constraint on the business not long after that. Nothing went wrong in the usual sense. The business simply outran the architecture it was built on, and every workaround added to keep going made the next stage harder to see.
This is where the broader market has landed too. In February 2026, Gartner described many older business systems as monolithic, for what it called their infamous inflexibility, and pointed to modern platforms that embrace modular composability as the way to add capability without a rebuild.1 The answer to a fragmented, overloaded stack is a single unified architecture, not another tool bolted onto the pile.
What does the cost of architectural lag look like at the leadership level?
The clearest measure is where the CEO's week goes. The more the architecture lags, the more executive time is spent inside the operation rather than ahead of it.
| Operational state | Where leadership time goes | Capacity to lead strategically |
|---|---|---|
| Chaos: legacy or manual stack | Most of the week resolving recurring failures and data mismatches | Low. The business runs the CEO. |
| Reactive: patchwork or partial ERP | A large share of the week still goes to firefighting between systems | Partial. Strategy competes with crises. |
| Strategic: unified architecture | Little time on system failures; attention moves to planning | High. Growth is no longer capped by the infrastructure. |
A unified architecture does more than cut the number of fires. It removes many of the conditions that start them, so the shift is toward planning rather than reacting, and it tends to arrive not long after a full deployment settles in.
How do I know if the chaos is coming from my systems or my team?
If four or more of these five patterns describe your week, the growth ceiling is structural, and no amount of hiring will move it on its own.
- The morning fire. The day starts by resolving the same category of system error or data mismatch, again.
- The expansion hold. A market opportunity gets postponed because no one trusts the systems to carry the extra load.
- The visibility gap. Basic operational questions, this month's margin, current inventory, billable hours, cannot be answered quickly.
- The single-system dependency. One person is the only administrator of a system the business cannot run without.
- The reconciliation meeting. Leadership spends its time reconciling conflicting numbers pulled from disconnected sources instead of deciding with them.
See what one unified architecture does to the week.
FireFlight is PCG's configurable platform that replaces the fragmented stack. Try it for 14 days, no obligation.
What operational problems does a unified architecture address at each growth stage?
The symptom differs by sector, but the root is the same: data that has to be moved by hand between systems that do not talk to each other.
Manufacturing and industrial
Floor data, job costing, and inventory bridged to accounting by hand, so the numbers never quite agree.
Environmental and compliance
Permit, manifest, and inspection records that must hold a full audit trail across jurisdictions.
Healthcare staffing and multi-site
Scheduling, credentialing, and payroll accuracy that have to stay in step across every facility.
Fleet and field service
Dispatch, compliance, and billing data carried back from the field and re-entered by hand.
What does the move from operational chaos to architectural stability look like?
PCG runs it in three phases, in parallel with live operations so the business keeps running. The scope and schedule depend on the current stack and are set during the first phase, not promised in advance.
- System stress testA diagnostic that maps the manual steps, the conflicting data, and the person-dependent processes, ranked by how much leadership time each one consumes. Nothing changes in your systems during this phase.
- Architectural harmonizationFireFlight is deployed in parallel with live operations, migrating the data and resolving the friction points in sequence, so the business keeps working while the new architecture comes together underneath it.
- Strategic handoffLeadership moves to management by exception, with automated flags and a real-time executive dashboard, so attention goes to the few things that need a decision rather than the many that used to need a rescue. Your data stays yours throughout, in a standard format.
Start with a clear picture of where the time goes.
Run a 14-day free trial of FireFlight and see what a unified architecture takes off the CEO's plate.
Frequently Asked Questions
1 Gartner, press release on embedded AI in cloud ERP applications, February 24, 2026, quoting Mike Helsel, Senior Director, Research, on legacy systems earning the descriptor "monolithic" for their inflexibility and on modern low-code flexibility and modular composability. gartner.com
2 Leadership time-allocation patterns reflect PCG pre-engagement assessments across mid-market operations.
Why do organizations end up with systems only one person can operate?
It happens gradually, usually during a stretch of fast growth. Someone capable builds a quick workaround, a macro, a script, a patch, to keep things moving, and it works. Over a few years those fixes accumulate into a system that only their author fully understands. What started as resourcefulness becomes a black box: a working system nobody else can safely change, and a business quietly dependent on one person staying, staying reachable, and remembering how it all fits together.
The 2026 data shows where that leads. In Uptime Institute's 2025 outage analysis, nearly 40 percent of organizations reported a major outage caused by human error in the previous three years, and about 85 percent of those traced back to staff not following procedures or to the procedures themselves being flawed.1 When the real procedure lives in one person's head rather than in the system, that is exactly the failure waiting to happen.
What does key-man dependency actually cost when it becomes an incident?
The cost is not only the hours of downtime. It is the hold one departure has over the whole operation, and it scales with how much of the system lives outside the software. The three models below show the difference in plain terms.
| Model | Reliance on one expert | What happens if that person leaves |
|---|---|---|
| Black box: undocumented custom | High. Day-to-day operation and every fix route through one person. | Operational paralysis until someone reverse-engineers the system. |
| Standard ERP: generic, documented | Moderate. Documented, but fitted to your process through settings only that person knows. | Significant disruption and a retraining lag while someone relearns the setup. |
| Transparent system: logic in the software | Minimal. The rules and validations live in the application, not in a person. | Little disruption. A qualified professional picks it up from the documented system. |
How do I know if my organization is already inside the Expert Trap?
Three warning signs tend to appear together. Two or more is a sign the risk is structural, not occasional.
The key-man query
When something breaks, staff call one specific person by name, not a process or a help desk.
The manual secret
Certain reports or functions depend on undocumented steps only one or two people know how to run.
The update fear
Staff avoid updates, new users, or workflow changes because they are afraid of breaking something no one can fix.
See what a system without a single point of failure feels like.
FireFlight is PCG's configurable platform, with the business logic in the software and documented from the start. Try it for 14 days, no obligation.
What makes a transparent system different from one that creates key-man dependency?
A transparent system keeps its rules where they can be seen and maintained. The business logic, the validations, the permissions, and the reports live inside the application rather than in a person's memory or a side file, and the architecture comes documented. Because it runs on standard, documented technology, .NET 10 with Razor Pages on SQL Server, any competent systems professional can operate and maintain it, not only the person who built it.
Just as important, your data stays yours. You own and control the information the system holds, in a standard, exportable format, so you are never locked in by a closed format or by one individual's knowledge. That is the real protection against key-man risk: not a promise that the expert will stay, but a system that does not need any single person in order to keep running.
What does eliminating key-man dependency actually look like?
PCG runs it in three phases, alongside live operations so nothing stops. The scope and schedule depend on how many dependencies the audit finds and are set during that audit, not promised in advance.
- Dependency auditStructured interviews and observation to map the undocumented processes and rank them by how critical each one is. The output is a written map of where the business currently depends on specific people.
- Logic extraction and system encodingThe knowledge that lives in people and side files is encoded into workflow rules, validations, permissions, and reporting inside the system, running in parallel with live operations so the business keeps working throughout.
- Documentation and handoffPCG delivers the architecture documentation and onboarding your team needs to run the system day to day, and your data stays under your control in a standard format. The knowledge now lives in the system, not in one person.
Find out where your single points of failure are.
Run a 14-day free trial of FireFlight and see how much of your operation's logic a transparent, documented system can hold.
Frequently Asked Questions
1 Uptime Institute, Annual Outage Analysis 2025 (announced May 6, 2025): nearly 40% of organizations reported a major human-error outage in the previous three years, and about 85% of those stemmed from staff not following procedures or from flawed procedures. uptimeinstitute.com
2 Microsoft, ".NET and .NET Core Support Policy": .NET 10 is the current long-term support release (released November 11, 2025; supported through November 14, 2028); .NET 8 reaches end of support on November 10, 2026. dotnet.microsoft.com
Why do most ERP migrations fail, and why does that fear cause organizations to stay too long?
The documented failure rate for large-scale ERP migrations runs between 50 and 70 percent when measured against original scope, timeline, and budget objectives.2 That number is not a reflection of bad vendors or bad intentions. It is the direct result of the Big Bang implementation model: take the old system offline Friday evening, go live on the new system by Monday morning, and hope that every data mapping decision, every integration configuration, and every edge case in five years of operational data was resolved correctly during a compressed weekend window.
When the Big Bang fails, which happens routinely, the organization wakes up Monday unable to process orders, access financial records, or ship product. Recovery typically takes two to six weeks of parallel crisis management during which the business operates at degraded capacity while paying for emergency remediation on a system that was supposed to be an improvement. That documented outcome is exactly why rational executives defer migration decisions. The fear is not irrational. What most executives do not know is that the Big Bang is not the only methodology available.
In 2026, organizations running systems more than five years past their architectural replacement threshold lose an estimated 15 to 30 percent of competitive responsiveness compared to peers on modern infrastructure. Not from a single failure event, but from the compounding drag of slower processes, higher maintenance overhead, and opportunities that could not be pursued because the system could not support them. The cost of staying is real and measurable. PCG's methodology removes the reason to stay.
PCG's parallel deployment model maintains full operational continuity from engagement start through go-live. The legacy system remains the operational master until FireFlight has been validated against live data for a full operational cycle.
What has changed in ERP migration in 2026?
The industry has moved toward the model PCG has used since 1995, and the 2026 data makes the shift visible.
- Phased and parallel approaches are now the majority preference. A 2026 industry survey found that 58.5 percent of organizations favor phased implementation over Big Bang, a reversal from the all-at-once default that dominated a decade ago.3
- Budget overruns remain the norm on ERP projects, at 64 percent, driven by underestimated staffing (38 percent), scope expansion during implementation (35 percent), and technical issues surfacing late (34 percent).3 A parallel validation window surfaces those issues before they reach a live cutover.
- Cloud ERP migrations now average around 14 months, and legacy or heavily customized applications carry the lowest success rate of any workload category at 61 percent.4 Custom-heavy systems are exactly the case where a validated parallel run matters most.
None of this is a reason to rush. It is a reason to migrate on a model that has already absorbed the risk the 2026 statistics keep measuring. The failure numbers describe Big Bang. They do not describe a parallel deployment that does not go live until the new system is proven against real data.
Big Bang vs. parallel deployment: what does the risk difference actually look like?
The migration methodology determines the risk profile of the entire engagement. Mapped below are the documented outcomes of the traditional Big Bang approach against PCG's parallel deployment model across five critical dimensions.
| Risk dimension | Traditional Big Bang implementation | PCG zero-downtime (FireFlight) |
|---|---|---|
| Operational downtime | 24 to 72+ hours planned; weeks if recovery required | Zero minutes throughout the entire process |
| Data integrity at go-live | Manual reconciliation post-cutover; typical error rate 5-15% | Validated against live data for 30-60 days before cutover |
| Implementation failure rate | 50-70% fail to meet original scope (Standish Group CHAOS Report) | No go-live until both parties confirm accuracy against live data |
| Staff transition pressure | Extreme: single high-stakes cutover with no fallback | Controlled: 30-60 days of real-world experience before cutover |
| Rollback capability | Typically none: legacy system decommissioned at cutover | Full rollback available until both parties validate final cutover |
The failure rate difference is not about PCG's experience relative to other vendors. It is about methodology. Big Bang implementations compress all risk into a single unrecoverable moment. PCG's parallel model distributes risk across a validation period and removes the unrecoverable moment entirely. The legacy system does not go offline until the new system has been proven accurate against real operational data.
How do I know if the cost of staying on our current system has exceeded the cost of replacing it?
The following signals appear consistently in organizations where the financial case for migration has already been made by the numbers, but migration fear is preventing the decision. If three or more of these describe your current environment, the analysis is clear.
- The Maintenance Crossover. Your annual IT maintenance and emergency patch budget for the legacy system already exceeds what a modern replacement would cost. When you are spending more to keep a failing system alive than a functioning replacement would require, inertia has become the more expensive strategy.
- The Revenue Ceiling. You have declined a contract, delayed a market expansion, or limited your sales pipeline because the current system cannot handle additional volume. Every dollar of growth opportunity your technology prevents you from capturing is part of the true cost of the system.
- The Security Gap. Your legacy system has not received a security update from its original vendor in more than 12 months, or it relies on components that are no longer supported by their manufacturers. Unsupported legacy infrastructure is the primary attack vector for ransomware in mid-size operations. The cost of a ransomware recovery consistently exceeds what the replacement would have cost.
- The Vendor Departure. Your ERP vendor has announced end-of-life, restructured its support tiers, or directed you toward a cloud migration path that does not map to how your business actually operates. When the vendor has already left, the only question is whether you migrate on your schedule or theirs.
- The Customization Wall. Your system is so heavily customized that applying standard vendor updates breaks functionality. Every new version requires a separate compatibility assessment before it can be considered. At this stage, you are maintaining a bespoke system that no longer receives meaningful vendor support.
What does zero-downtime migration actually look like in practice?
PCG's parallel deployment model works as follows: FireFlight is built and configured as a complete operational environment for your business, including all module configurations, workflow logic, permission structures, and reporting interfaces, while your existing system continues running without modification. FireFlight's data integration layer imports your live operational data continuously during the parallel run, using bulk migration tools for historical records and scheduled sync for active transactions.
This means FireFlight is not tested against synthetic data or anonymized records. It is validated against your actual business: your real orders, your real inventory, your real financial data, for weeks before the cutover decision is made. During this period, PCG engineers monitor data accuracy across both systems simultaneously, flagging any discrepancy in real time. Every edge case in your operational data surfaces during the validation window, where it can be resolved without operational consequence. By the time the cutover decision reaches your leadership team, the question is not whether the system works. It has already been proven to work.
Data Curation and Foundation Build
PCG extracts your complete data history from the legacy system and performs a full curation: cleaning inconsistent records, resolving duplicates, standardizing formats, and mapping every data element to the FireFlight architecture. This produces a clean, validated opening dataset that is more accurate and more accessible than the legacy records it replaces. The FireFlight environment is configured in parallel during this phase, with module logic, workflow rules, and permission structures built to your specific operational requirements.
Parallel Deployment and Live Validation
FireFlight runs in shadow mode alongside your legacy system, processing the same live operational data and allowing your team to interact with the new environment without it affecting production. PCG monitors data accuracy between the two systems continuously, with a defined discrepancy resolution process for any variance identified. Your team learns the new interface during this phase, with the legacy system available as a reference and fallback. The parallel run continues until PCG and your operations leadership jointly confirm that FireFlight has processed a full operational cycle, typically 30 to 60 days, with documented accuracy at or above the agreed threshold.
Precision Cutover and Post-Go-Live Validation
Once both PCG and your leadership team have confirmed FireFlight's accuracy, the cutover is executed during a scheduled, low-activity window. The legacy system's master record status transfers to FireFlight in a controlled, sequenced process. From that point, the legacy system remains accessible in read-only mode for a defined post-cutover validation period, providing a complete rollback option if any unforeseen issue surfaces in the first days of live operation. In practice, the parallel validation process is thorough enough that post-cutover issues are rare and minor. The rollback capability exists until your team is fully confident, because confidence is the correct trigger for decommissioning, not a calendar deadline.
Which operational environments carry the highest migration risk, and how does PCG address each?
Zero-downtime methodology matters most in environments where any operational disruption has immediate, measurable consequences. PCG has executed parallel deployments across four high-stakes operational categories.
Municipal and Commercial Fleet Operations
Fleet fueling systems, dispatch records, and DOT compliance documentation cannot go offline during migration. PCG delivered a full system replacement for a Top-5 U.S. metropolitan fleet using the parallel deployment model. The client operated on legacy infrastructure through the entire build phase, with the cutover on a Sunday morning and Monday operations running on FireFlight without interruption.
Healthcare Staffing and Credentialing
Scheduling, credentialing, and payroll for multi-facility staffing organizations require accuracy across all three functions simultaneously during any transition period. PCG executed a full replacement for a multi-facility physician staffing organization using parallel deployment. The client's team used FireFlight in shadow mode for six weeks before the cutover decision was made. Zero data loss, and zero post-cutover rollback required.
Environmental Compliance Operations
Air permit tracking, waste manifest records, and remediation documentation must maintain an unbroken audit trail through any system transition. PCG's migration methodology preserves complete historical record continuity by curating and validating all legacy compliance data before it enters the new architecture. The audit trail does not have a gap, and the regulatory record stays complete.
Manufacturing with Active Production Floor
Job costing, inventory, and production scheduling cannot tolerate a migration window that takes the system offline during a production run. PCG's parallel model means the production floor never stops. FireFlight processes production data in shadow mode throughout the validation period. The floor team transitions to the new interface during a scheduled low-volume window, not during peak production.
What has PCG delivered, and in what environments?
Allison Woolbert designed PCG's zero-downtime migration methodology after three decades of managing system transitions in environments where the margin for operational disruption was effectively zero. Her enterprise work includes mission-critical system transitions on projects with corporations such as ExxonMobil, Nabisco, and AXA Financial, where a failed cutover carries direct and measurable business consequences. PCG was founded in 1995. The parallel deployment model has been the foundation of every migration engagement since.
The physician staffing deployment referenced above represents the clearest case study for this methodology in a high-stakes environment, where the client could not stop processing schedules, could not lose credentialing records mid-cycle, and could not delay payroll under any circumstances. PCG ran FireFlight in parallel for six weeks, validated every module against live operational data, and executed the cutover on a Sunday. Every facility was fully operational on FireFlight by Monday. The legacy system was decommissioned the following week after the post-cutover validation confirmed no issues.
If your legacy ERP is a discontinued platform rather than a modern system nearing end of life, the migration path differs, and PCG covers it in migrating off Sage, Great Plains, and Peachtree.
Key takeaways
- Between 50 and 70 percent of large ERP migrations fail against scope, timeline, or budget, and that failure rate is a property of the Big Bang model, not of migration itself.
- PCG's parallel deployment keeps the legacy system as the operational master until FireFlight is validated against live data for 30 to 60 days. The cutover carries zero planned downtime and a full rollback path.
- The 2026 data confirms the shift: 58.5 percent of organizations now prefer phased over Big Bang, while 64 percent of ERP projects still run over budget, most often from scope expansion that a parallel run exposes early.
- Custom-heavy and legacy applications have the lowest cloud-migration success rate at 61 percent, which is exactly the case where a validated parallel run matters most.
- The correct decommission trigger is confirmed performance against real data, not a calendar deadline. PCG has recorded no post-cutover rollbacks across its parallel deployments.
What happens if data discrepancies surface during the parallel validation run?
How long does the full migration take from engagement start to cutover?
Can we actually roll back to the legacy system if something goes wrong after cutover?
What happens to our third-party integrations during the migration?
How does staff training work when the system changes during active operations?
Our current system has years of custom business logic. How does PCG preserve that during migration?
How is our historical data handled? We cannot lose years of operational records.
What is the first step for an organization ready to explore a zero-downtime migration?
Sources
- Zero-downtime migration outcomes based on PCG deployment records across 14 mid-market ERP replacements, 2019-2026. Parallel validation periods ranged from 30 to 68 days across engagements.
- Implementation failure rate data from the Standish Group CHAOS Report, cited across multiple years. Big Bang failure rate estimates based on published industry analysis of enterprise ERP implementation outcomes, 2020-2025.
- DocuClipper, Cloud ERP statistics 2026 (58.5% phased-implementation preference; 64% budget-overrun rate with staffing, scope, and technical drivers), as compiled in 2026 industry reporting.
- 2026 cloud migration statistics: ERP migrations average roughly 14 months; legacy and custom application migrations carry a 61% success rate, the lowest of any workload category.