Who builds it, what it has to do in 2026, and when custom wins over SaaS
Phoenix Consultants Group builds custom software for environmental remediation tracking, chain of custody, and audit reports across EPA Superfund, CERCLA, RCRA, and state DEP programs. PCG has been engineering remediation systems since 1995, including Superfund soil tracking, ground water monitoring, and EPA Title V air quality platforms used by Fortune 100 refineries and federal cleanup operations.
What does environmental remediation tracking software need to do in 2026?
The regulatory floor for remediation operators moved in 2025 and 2026, and most off-the-shelf platforms have not caught up. A remediation tracking system built today has to cover four things that were not standard requirements three years ago.
First, PFAS as Superfund hazardous substances. EPA designated PFOA and PFOS as hazardous substances under CERCLA in a final rule effective July 8, 2024.1 The agency confirmed in September 2025 that it will retain the designation and is developing a Section 102(a) Framework Rule for future PFAS hazardous substance designations.2 What this means operationally: previously closed sites can be reopened, new sites enter the National Priorities List with a broader contaminant scope, and chain of custody documentation now has to track substances that were not on the regulated list when most legacy systems were designed.
Second, the 2026 Five-Year Review cycle. EPA opened the 2026 review cycle on eight Superfund sites this year.3 Five-Year Reviews are not new, but the documentation expectation has tightened. A review now expects continuous performance data from the operator, not a binder produced the week before the EPA team arrives. A remediation tracking system that does not produce that record automatically becomes the bottleneck of the review.
Third, the new TSCA section 6(g) TCE exemption requirements took effect February 17, 2026, affecting labs that support remediation analysis.4 Workflow integration between the operator and the lab is no longer optional.
Fourth, the PFAS reporting rule under TSCA opens for submission on January 31, 2027, or 60 days after the rule is finalized, whichever comes first.5 Waste management and remediation services (NAICS code 562) are covered. An operator that does not know which of their historical projects are reportable is behind the curve already.
Off-the-shelf EHS platforms address these regulations in their roadmaps. Custom software addresses them in the operator's actual workflow.
Why off-the-shelf EHS platforms fail mid-size remediation firms
There are good SaaS platforms in this category. Matidor handles environmental site assessment and project tracking with a strong map interface, particularly for consultancies running 20-plus concurrent assessments across multiple sites. EVX Software was built specifically for environmental and engineering consultancies, with billing and time tracking baked in. EnFlection from Trihydro is the most regulation-specific of the four, supporting CERCLA, RCRA, NPDES, and Class VI carbon capture workflows out of the box. ERA Environmental rounds out the category. The vendor has been in environmental software since 1995, the same year PCG was founded.
These platforms work well when the operator's process matches the platform's design. They fail in three predictable ways when the operator's process is the differentiator.
Reporting templates miss the regulator
A state DEP reviewer in New Jersey accepts a different format than an EPA Region 9 program officer in California. Multi-jurisdiction firms end up exporting from the SaaS platform and reformatting in Excel before submission.
Instrument and lab integrations are missing
Custom remediation work uses specific lab LIMS systems and field sampling instruments. SaaS platforms support the top integrations. They do not support the one your operation has used for fifteen years.
No source code, no data ownership
When the SaaS vendor pivots its roadmap, sunsets a feature, or raises pricing, the operator has no recourse other than to migrate the data again. For records tied to twenty-year regulatory audits, that risk is material.
PCG has migrated operators away from SaaS platforms comparable to the four named above. In every case the trigger was the same. The operation grew past what the platform was designed to do. The cost of working around the platform exceeded the cost of building a system that fit.
When custom software wins over SaaS for remediation tracking
Custom does not win every project. A small environmental services firm with one office, one state regulator, and a standard workflow should buy a SaaS platform. That is the right answer.
Custom wins in three specific situations.
Multi-jurisdiction reporting where no SaaS template fits. Remediation operators working across three or more state DEP programs plus federal EPA oversight produce reports in formats that no platform can template-match. Building the reports in custom software once produces correct output every time. Building them by exporting and reformatting from SaaS produces a quarterly fire drill.
Integration with instrumentation or lab systems that the operator depends on. When the field data comes from specific sampling equipment and the lab data comes from a specific LIMS, the integration layer is the whole project. Custom software builds that layer once. SaaS asks the operator to change tools.
Source code ownership for long-cycle regulatory audits. Superfund and other long-cycle cleanup programs run over decades. The software supporting a twenty-year remediation needs to outlive any SaaS vendor's business decisions.
PCG delivers source code ownership to every client as a contractual term, not a marketing claim. For remediation systems that have to support decade-long regulatory audits, that ownership is non-negotiable. When the vendor relationship ends, the operator still owns the system.
What PCG has actually built for environmental operators
Four projects from the PCG case study library illustrate the pattern across remediation, monitoring, regulatory permitting, and chemical handling.
Source-to-destination chain of custody for every soil unit. Forward projection on remaining contaminated volumes. Regulatory output aligned with EPA Superfund program officers.
Time-series data across monitored wells. Anomaly detection on threshold exceedances. Multi-site monitoring with state environmental agency reporting.
Tens of thousands of emissions calculations for a Clean Air Act permit application. Worst-case and best-case modeling. Complete audit trail. Permit approved.
Multi-client chemical production and shipping. Chain of custody from production through delivery. OSHA HazCom 2012 / GHS regulatory alignment from one architecture.
Detailed case studies are available for each project. Superfund Soil Remediation. Ground Water Monitoring. EPA Title V Air Quality.
The pattern across these projects is consistent. PCG did not arrive with a product. PCG arrived with engineers who learned the regulatory framework, the operational workflow, and the existing data structure before any code was written.
What to ask a custom software developer before signing
Do they do a diagnostic before quoting? Any developer who quotes a timeline or a price before understanding the data, the regulatory exposure, and the existing workflow is guessing. A serious custom development firm runs a diagnostic engagement first and produces a written scope document. PCG offers this diagnostic at no cost, because the diagnostic is how a real engagement should start.
Do they hand over source code? If the contract does not specify source code delivery, the operator is renting software. For remediation tracking that has to outlive the developer relationship, ownership is non-negotiable.
Have they built for the regulatory framework the operator works under? Building for EPA Superfund is different from building for state DEP. Building for OSHA HazCom is different from building for USDA APHIS. The right developer can name the specific frameworks in their delivered work, not in generic marketing copy.
Do they support post-deployment when regulations change? Regulations change. CERCLA scope changed in 2024 with the PFAS hazardous designation. The 2026 PFAS Destruction and Disposal Interim Guidance from EPA shifted from triennial updates to annual updates.6 A custom remediation system needs a support relationship that handles those changes within weeks, not quarters.
Will the operator's actual user talk to the developer's actual engineer? Operators have been burned by sales engineers who promised one thing and delivery teams who built another. The right answer is that the same person who scopes the project is involved through delivery.
Are they willing to walk away if custom is the wrong answer? A custom development firm that recommends SaaS when SaaS is the right answer is a custom development firm worth hiring. PCG turns down projects that should not be custom. That is not a weakness, it is a filter.
Which path fits your remediation operation?
Full Custom Development if
Your regulatory exposure or operational scale needs software built around your process.
- Active EPA Superfund or CERCLA cleanup with chain-of-custody requirements
- Multi-jurisdiction reporting across three or more state DEP programs
- Specific lab LIMS or field instrumentation that no SaaS supports
- Decade-long regulatory audit cycles requiring source code ownership
- Fortune 100 / Fortune 500 facility with non-standard data architecture
FireFlight Accelerated Custom if
You need a tailored system fast and your workflow is close to a known pattern.
- Mid-size environmental consultancy with standard remediation workflow
- Compliance tracking across permits, certifications, and audit deadlines
- Need scheduling, dispatching, document tracking from day one
- Field-to-office task handoff with low-connectivity tablet support
- Want custom output without starting engineering from a blank page
The free diagnostic consultation tells you which path fits your situation.
A note on FireFlight, PCG's faster path to a custom system
For operators who need a tailored system but cannot wait the timeline a fully custom build requires, PCG offers FireFlight: a faster path to a custom system, built on PCG's engineering foundation and configured to the operator's specific workflow.7 FireFlight is not off-the-shelf. It is custom delivery accelerated by reusable modules PCG has built over thirty years of project work. It applies when the operator's process is close enough to a known pattern that the engineering does not have to start from a blank page.
For Superfund operators, multi-jurisdiction environmental consultancies, and EHS-driven industrial operations with unique regulatory exposure, the answer is usually full custom development. The diagnostic engagement determines which path fits.
Start with a free diagnostic consultation.
PCG will map your current remediation tracking workflow, assess your regulatory exposure, and tell you whether custom development, FireFlight accelerated build, or a SaaS platform is the right answer. No commitment required.
Frequently Asked Questions
At minimum, a 2026 remediation tracking system supports EPA Superfund and CERCLA reporting, RCRA hazardous waste documentation, state DEP environmental compliance, and the new PFAS reporting framework opening in 2027. Operators in specific industries also need OSHA HazCom 2012 / GHS alignment for chemical handling, NPDES discharge permits, and applicable state-level air and water quality programs.
Yes. PCG has built source-to-destination chain of custody systems for active EPA Superfund cleanups, tracking contaminated soil from excavation through transport, treatment, and final disposal. The system produces the regulatory output that EPA Superfund program officers expect during oversight.
SaaS platforms are designed for the operator's process to match the platform. Custom software is designed for the platform to match the operator's process. SaaS wins for small, standard operations. Custom wins when the operator has multi-jurisdiction reporting, specific instrumentation integrations, or a regulatory audit cycle that runs longer than any SaaS vendor's product roadmap.
The client owns the source code. PCG delivers source code ownership as a contractual term, not as a marketing claim. This is non-negotiable for remediation systems that need to support decade-long regulatory audits.
Project length depends on the complexity of the operation, the number of regulatory frameworks the system has to satisfy, and the state of the existing data. A small operation tracking a single Superfund site with a documented spreadsheet workflow is a different project than a multi-site environmental services firm with twenty years of historical data across three state DEP jurisdictions. PCG starts every project with a free diagnostic consultation that establishes the scope before any development quote is given. The written scope document, not a guess, is what determines the timeline.
Yes. PCG provides ongoing support relationships with environmental operators where regulatory changes are part of the operating environment. When CERCLA scope expanded in 2024 to include PFOA and PFOS, when EPA shifted the PFAS Destruction and Disposal Interim Guidance to annual updates in 2026, PCG-built systems were updated to match. The support model is part of the engagement, not an upsell.
1 U.S. Environmental Protection Agency, Designation of Perfluorooctanoic Acid (PFOA) and Perfluorooctanesulfonic Acid (PFOS) as CERCLA Hazardous Substances, final rule effective July 8, 2024. epa.gov/superfund/designation-perfluorooctanoic-acid-pfoa-and-perfluorooctanesulfonic-acid-pfos-cercla
2 U.S. Environmental Protection Agency announcement, September 17, 2025, retaining PFOA and PFOS CERCLA designation and developing Section 102(a) Framework Rule. Reported by Babst Calland, September 2025.
3 STL.News, EPA to Reexamine Eight Superfund Sites in 2026 to Ensure Cleanups Still Protect Communities, February 2026.
4 Lab Manager, EPA Delays Trichloroethylene (TCE) Exemption Requirements to 2026, November 2025.
5 New Jersey Business and Industry Association, EPA Changes Submission Date on Proposed PFAS Reporting Rule, April 2026.
6 U.S. Environmental Protection Agency, 2026 Interim Guidance on the Destruction and Disposal of PFAS, April 2026.
7 Phoenix Consultants Group, FireFlight Project Overview, phxconsultants.com/fireflight-project/, accessed May 2026.
This article is informational and reflects regulatory information current as of May 2026. It is not legal, regulatory, or compliance advice for any specific operation. Operators with active EPA Superfund, CERCLA, RCRA, state DEP, or related obligations should consult their regulatory counsel and the relevant agency directly for guidance on their specific situation. Phoenix Consultants Group founded 1995.
AI integration is no longer optional. For most businesses running operations software in 2026, it is mission critical. PCG connects your existing systems directly to AI so your team can query live data in plain English, automate high-volume repetitive tasks, and move work between field and office without re-entering anything. Most integrations complete in 2 to 4 weeks.
Why is AI integration mission critical in 2026?
In 2026, businesses that cannot query their own data in real time are making slower decisions than their competitors who can. The gap between a team that waits two days for a report and a team that asks a question and gets an answer in ten seconds is not a technology gap. It is an operational gap that compounds every day it goes unaddressed.
Knowledge workers spend an average of 3.6 hours per week searching for information that already exists in their own systems.1 That is time that produces nothing. AI integration eliminates that category of work entirely by connecting the people who need answers directly to the data that holds them.
Beyond productivity, there is a security dimension that most businesses running older operations software have not addressed. Platforms that no longer receive active development carry serious vulnerabilities: outdated encryption, no audit trails, no access controls built to current standards. Integrating AI from a vetted provider adds an authenticated, monitored layer on top of those systems that reduces that exposure significantly while the migration to a modern platform is planned.
What does AI integration actually do for your operation?
PCG builds three types of AI integration depending on what your operation needs. Natural language database access means your staff types a question and the system returns the answer from your live data, not a canned report generated the night before. Desktop agent automation handles the repeatable parts of your workflow without being asked. Cross-device task coordination puts a field technician's tablet entry directly on the right desktop, with full context, no phone call needed.
None of these require replacing what you already have. They layer on top of your existing software. That is the only practical way to add AI to a business that cannot afford to stop running while something new is built.
Natural Language Database Access
Ask your own live data questions in plain English. No SQL. No waiting for a report. The answer comes from your actual database, not a dashboard someone built six months ago.
Desktop Agent Automation
AI agents that handle the tasks your team runs by rote every day. Routing records, flagging exceptions, generating routine output. Your staff keeps doing the work that requires judgment.
Tablet-to-Desktop Task Handoff
Field technicians log findings and set tasks on a tablet. Office staff see it immediately on their desktop with full context. Nothing re-entered. Nothing lost between field and office.
Which AI providers does PCG work with?
PCG integrates with four AI providers. The right choice depends on your operation's data sensitivity requirements and the specific tasks being automated. Every engagement starts with a free consultation to assess which provider fits your situation.
Strong reasoning and long-context analysis. Well-suited for compliance documentation review and complex natural language queries against structured data.
Broad capability across text generation and structured data. A proven choice for desktop agent automation and workflow integration in operations environments.
Strong multimodal capability. Well-suited for operations that need AI to process both documents and structured data from the same workflow.
Runs entirely on your own hardware. Zero external data transmission. Nothing leaves your building. The right choice when full data sovereignty is non-negotiable.
For operations where data cannot leave the premises, Ollama is the answer. It runs entirely on your own hardware with zero external data transmission. PCG has deployed Ollama for clients in environmental compliance and industrial operations where regulatory and liability requirements make cloud AI impractical regardless of the provider's security certifications.
Can you integrate AI with our existing software, including third-party platforms?
For custom software and proprietary systems PCG has built or has direct database access to, AI integration is straightforward. The natural language layer connects directly to the underlying data structure.
For third-party SaaS platforms, the answer is evaluated case by case. Some platforms expose APIs that support AI integration at the data level. Others restrict external access at the platform level, which makes meaningful AI integration technically impossible without violating the platform's terms of service. PCG will not promise SaaS integration without first assessing what the platform actually allows. That assessment happens in the free consultation before any work is scoped.
Most integrations PCG completes are finished in 2 to 4 weeks from signed scope. The free consultation determines whether your specific systems are integration-ready and what the realistic timeline looks like for your situation.
Does it make sense to add AI to older software, or should we migrate first?
This depends entirely on what platform you are running. For custom software built on a supported stack, AI integration is the right move. You get AI capability in 2 to 4 weeks without disrupting an operation that is working.
For platforms that no longer receive active development, Access being the clearest example, adding AI integration is not the right answer. You would be investing in a capability built on a foundation that has no future. When the platform fails, everything built on top of it fails with it.
The right path for those operations is migrating to FireFlight Data System, which has AI-powered natural language reporting built into the architecture from the start. PCG has been migrating Access databases and legacy applications since 1995. Most migrations complete in weeks, not months. The free consultation maps your current system and tells you which path applies before you commit to anything.
Which path fits your situation?
AI Integration if
Your software is on a supported platform. You want AI capability on top of it.
- Your software was built on a currently supported stack
- Core workflows run reliably without daily workarounds
- Your data is structured and consistent in a current database
- You want natural language queries, desktop agent automation, or field-to-office task handoff
- Operational disruption from replacement is not acceptable right now
Migrate to FireFlight if
Your platform no longer receives active development. Build on a foundation with a future.
- You are running Access, VB6, or other software no longer receiving active development
- Only one or two people understand how the system works without breaking it
- Maintenance costs keep rising while reliability keeps declining
- You need AI reporting from day one, not bolted onto a platform with no runway
- Security vulnerabilities in the current platform are a compliance or liability concern
The free 30-minute consultation tells you exactly which situation you are in.
Start with a free 30-minute consultation.
PCG will assess your current systems, tell you whether AI integration or migration is the right path, and give you a realistic timeline. No commitment required.
Frequently Asked Questions
Most integrations complete in 2 to 4 weeks from signed scope. Natural language reporting on an existing system with clean data is typically on the shorter end. Desktop agent automation takes a bit longer depending on how many workflows are being built. The free consultation gives you a realistic timeline for your specific situation before any work begins.
Migrate. Access no longer receives active development and adding AI integration on top of it does not change that. You would be investing in capability built on a platform with no future. The right path is migrating to FireFlight, which has AI-powered natural language reporting built into the architecture from the start. PCG has been migrating Access databases since the platform's early years. Most migrations complete in weeks. The free consultation maps your data structure and tells you what the migration looks like before you commit to anything.
It depends on what the platform allows. Some SaaS platforms expose APIs that support meaningful AI integration at the data level. Others restrict external access in ways that make it technically impossible or a terms-of-service violation. PCG will not commit to SaaS integration without first assessing what the specific platform permits. That assessment happens in the free consultation before any work is scoped or priced.
Ollama runs AI models entirely on your own hardware. Nothing is transmitted to an external server. Not a query, not a response, not metadata. For operations where data sovereignty is non-negotiable, whether for regulatory reasons, client confidentiality requirements, or liability exposure, Ollama is the only option that genuinely keeps your data inside your building. Cloud-based providers like Claude and GPT-4 offer strong security certifications, but data does leave your infrastructure. If that is not acceptable, Ollama is the answer.
Platforms that no longer receive active development typically have outdated encryption, no modern audit trail capability, and access controls that predate current standards. Adding an AI integration layer does not fix those vulnerabilities directly, but it does add an authenticated, monitored access point on top of the system that reduces exposure significantly. Every query through the AI layer is logged, role-controlled, and auditable. That is a meaningful security improvement over teams accessing the underlying system directly through interfaces that were never designed for that level of oversight.
Yes. PCG regularly works with orphaned software where the original developer is gone and documentation is limited. The consultation includes reverse-engineering the data structure to understand what the system holds and how it is organized. Once that map exists, connecting an AI layer to the underlying database is standard work. The age of the software or the absence of the original developer does not prevent it, provided the platform itself is still viable.
ChatGPT and Copilot know nothing about your specific database, your specific workflows, or the records your team has been building for years. When you ask Copilot a question about your own data, it either cannot answer or produces something plausible that is not based on your actual records. PCG's AI integrations are connected to your data. The natural language interface queries your actual live database and returns answers drawn from your operation as it stands today, not a generic description of how businesses like yours typically work.
Field technicians use a tablet interface connected to the same database as the desktop application in the office. When a technician logs a finding or sets a follow-up task, that information writes to the live database immediately. The desktop user sees it in real time with full context. No sync delay. No data re-entry. The tablet interface works in low-connectivity environments and queues updates until a connection is available without losing anything.
1 IDC Knowledge Worker Productivity Study, 2025. Average time spent by knowledge workers searching for information across enterprise systems.
2 Automation Anywhere SMB Productivity Benchmark Report, Q4 2025. Process time savings across 400 U.S. businesses with 10-250 employees.
3 Gartner Digital Workplace Report, January 2026. AI tool adoption rates: native integrations vs. standalone AI tools in the same organization.
Why is this decision harder in 2026 than it used to be?
The off-the-shelf market has expanded significantly. There is now a SaaS product for almost every common business function, and entry pricing is low enough that it is easy to start without thinking carefully about fit. The problem shows up 18 months later when the workarounds have accumulated, the data is spread across four systems that do not talk to each other, and the monthly subscription costs have grown past what a custom application would have cost to build.
At the same time, custom software has become more accessible. The tools and frameworks available in 2026 mean that a well-scoped custom application can be built faster and for less than it would have taken in 2010. The decision is not as lopsided toward off-the-shelf as it was when custom development meant 18-month timelines and six-figure budgets for anything functional.
How do off-the-shelf and custom software actually compare?
The comparison that matters is total cost of ownership over five years, not the sticker price on day one. Off-the-shelf software has a low barrier to entry and a high cost of accumulation. Custom software has a higher initial investment and a much lower cost of ongoing friction.
| Off-the-shelf | Custom software | |
|---|---|---|
| Initial cost | Low to moderate. Subscription starts immediately. | Higher upfront. Scope determines the number. The diagnostic produces a fixed price. |
| Time to deploy | Days to weeks for basic use. Months for full configuration. | Determined by the diagnostic, based on scope, integrations, and data migration. |
| Fit to your process | You adapt to the software. Workarounds accumulate over time. | Software adapts to your process. No workarounds by design. |
| Data ownership | Data lives in the vendor's system. Export options vary by contract. | You own the data and the database. No vendor lock-in. |
| Ongoing cost | Per-seat fees that grow with your team. Pricing increases annually. | Flat monthly support retainer. No per-seat fees. No annual price increases. |
| Vendor risk | Vendor discontinues the product, raises prices, or gets acquired and changes terms. | You own the source code. No vendor dependency. |
| Integration | Limited to the vendor's API. Often requires middleware or manual exports. | Built to connect to what you already use. |
| Competitive advantage | Every competitor has access to the same tool. | Your process, your rules, your advantage. |
When does off-the-shelf software make sense?
Off-the-shelf software is the right answer when the problem it solves is genuinely common and your version of that problem is not meaningfully different from everyone else's. Accounting, email, document management, basic project tracking. These are well-served by existing products because the underlying process is largely the same across businesses.
It also makes sense as a starting point when a business does not yet know what it needs. Running a new operation on an existing tool for 12 to 18 months produces a much clearer picture of where the tool falls short than any requirements-gathering process. Some businesses discover that the off-the-shelf option is good enough permanently. Others discover exactly what a custom system would need to do.
Off-the-shelf works well when your process matches the standard workflow the product was built around, when the problem is common across your industry, when your team size fits within the vendor's standard tiers, when integration with other systems is not a primary requirement, and when the vendor has a long track record and a stable business.
When does custom software make sense?
Custom software makes sense when the gap between what existing products do and what your business actually needs has a measurable cost. That cost can be staff hours spent on workarounds, errors introduced by manual data transfers between systems, compliance requirements that no standard product meets, or a process that is genuinely different from what any vendor has built for.
Industries with specific regulatory requirements are a consistent source of custom software demand. Environmental compliance, industrial safety, healthcare credentialing, fleet operations with fuel tracking requirements. These areas have off-the-shelf options, but the options either cover the general case inadequately or cost enterprise prices that a 30-person firm cannot justify. A custom application built specifically for what those businesses do costs less over five years than the enterprise platform, and it actually fits.
You have outgrown off-the-shelf when
Signs to watch for
- Staff maintain a separate spreadsheet to track what the software misses
- Data gets exported and re-entered somewhere else
- The same workaround has been in place for more than a year
- New employees need weeks to learn the workarounds, not the software
Custom is the right call when
Signs to act on
- Your process has regulatory specifics no standard product addresses
- You have looked at five products and none fit without significant customization
- Your competitive edge comes from how you do the work
- Generic software erodes the advantage that makes you different
What does total cost of ownership actually look like over five years?
SaaS platforms look inexpensive at the start and expensive by year three. Per-seat pricing compounds as the team grows. Annual price increases compound on top of that. Workaround time, measured in staff hours per week, is rarely included in the original purchase decision but adds up to a real number by year two.
The crossover point between SaaS and custom typically appears in the middle of the five-year window. Before that point, the off-the-shelf option is cheaper on paper. After it, every additional year on a per-seat model with annual increases costs more than a custom application with a flat support retainer. The exact crossover depends on team size, vendor pricing structure, and how honestly the workaround cost is counted.
PCG does not argue that custom software is always the answer. The diagnostic conversation exists precisely to have an honest discussion about whether custom development makes sense before quoting a project. Some businesses that call PCG are better served by a configured off-the-shelf product. PCG will say so directly and will not take a project that does not make financial sense for the client.
Can you start with off-the-shelf and migrate to custom later?
Yes, and for many businesses this is the most practical path. Starting with an existing tool while a business is still defining its process avoids building custom software around requirements that will change in the first year. The risk is accumulating technical debt in the off-the-shelf platform. Data formats and integrations make migration harder the longer they sit.
PCG has migrated businesses off SaaS platforms into custom applications multiple times. The migration complexity depends entirely on how much data has accumulated and how accessible it is. Vendors with clean export APIs make the process straightforward. Vendors who treat data export as a retention tool make it considerably harder. Before committing to any SaaS platform that will hold significant operational data, verify the export terms in the contract.
The businesses that transition most smoothly from off-the-shelf to custom are the ones that maintained clean data practices from the start and documented their actual process rather than the process the software forced on them. That documentation becomes the specification for the custom build.
Not sure which direction is right for your business?
Start with a diagnostic conversation. PCG will tell you honestly if off-the-shelf is the better call.
Frequently Asked Questions
PCG migrates Visual Basic 6 applications to modern .NET. We have been doing this work since VB6 was current software, which means we understand what these systems actually do before touching a line of code. Most migrations take 8 to 20 weeks depending on application size and documentation available. Your business logic comes through intact. So does your data.
Why are VB6 applications failing in 2026?
Visual Basic 6 reached end of support from Microsoft in 2008. The runtime persisted through Windows compatibility layers, but that window is closing fast. In 2026, the failure points are stacking up: 64-bit Windows dropping 32-bit COM component support, third-party controls with no working installers, and hardware refreshes that simply will not run the old runtime environment at all.
The businesses still running VB6 applications are not doing so because they prefer VB6. They are running them because the application works and the migration felt expensive. Nobody wanted to touch something that was not broken. In 2026, more of those applications are breaking. A Windows update that rolled out silently at 2am is a common trigger. So is a new machine purchase where IT discovers the application will not install.
- 64-bit Windows environments removing legacy 32-bit COM support
- ActiveX controls with no current vendor support or installer
- Crystal Reports components tied to VB6 versions with no upgrade path
- DAO and RDO data access layers deprecated in current SQL Server
- Hardware refreshes where the VB6 runtime simply will not install
- Windows 11 compatibility breaks that appear without warning after updates
- SSL/TLS library dependencies that no longer function in modern network environments
The cost of waiting is no longer theoretical. Every month a VB6 application stays in production on modern hardware is a month closer to a failure that forces the migration under crisis conditions rather than planned ones. PCG has handled both scenarios. The planned migration costs significantly less.1
What does PCG actually do during a VB6 to .NET migration?
The migration is not a code conversion. Automated tools exist that will translate VB6 syntax to VB.NET syntax line by line, and the result is almost always unmaintainable code that carries every architectural problem of the original into the new platform. PCG does not use that approach.
The work starts with understanding what the application does. VB6 systems running for 15 or 20 years often contain business logic that exists nowhere else in the organization. Rules encoded in 2004 by a developer who is no longer there, handling edge cases that nobody currently remembers exist. PCG documents that logic before writing a single line of new code.
PCG reads the existing VB6 codebase and produces a plain-English document of what the application does and what business rules are embedded in the code. This becomes the specification for the new system.
Based on what the application does and how it is used, PCG recommends the target platform. Most VB6 applications migrate to C# .NET Core with a web front end. Desktop applications with specific hardware dependencies may stay as Windows desktop apps, rebuilt in modern WPF or WinForms. The decision is driven by the business need, not by what is easiest to build.
VB6 applications typically connect to Access databases or older SQL Server versions. PCG migrates the data to a current SQL Server schema, cleaning and normalizing records in the process. The new application connects to clean data from day one.
The new application is built against the documented specification. Before cutover, both systems run in parallel on real data. Discrepancies surface before the old system is retired. PCG does not do big-bang cutovers on business-critical applications.
Staff training on the new system, written documentation of how it works, and a support retainer option so PCG remains available after go-live. The goal is a team that can operate the new system without calling PCG for every question.
Can PCG migrate a VB6 application if the original developer is gone?
Yes. This is the most common situation PCG encounters on VB6 projects. The developer who built the system retired, changed careers, or passed away. The documentation ranges from thin to nonexistent. The people currently using the application can describe what it does from the outside, but nobody alive has read the code in years.
PCG starts from the source code itself. If source code is available, the audit process reconstructs what the application does from the inside out. If only a compiled executable exists, PCG works from the database schema and user interviews to reconstruct the business logic before any rebuild begins. That process takes longer and costs more, but the result is the same: a documented understanding of what the system does before migration work starts.
The technology stack PCG works in for these migrations is the same one the original VB6 systems connected to. SQL Server in every version from 6.5 forward. Access databases from every era. COM components and ActiveX controls are familiar territory for this team. So are the Crystal Reports versions that shipped alongside VB6.
How long does a VB6 to .NET migration actually take?
The honest range is 8 to 20 weeks for most applications PCG handles. A single-purpose VB6 application with a clean Access backend and good source code documentation can be migrated in 8 to 10 weeks. A large multi-module system built over 15 years by multiple developers, with no documentation and a database that has grown organically since 1998, takes closer to 20 weeks or more.
The variables that drive timeline more than anything else are documentation state and data quality. An application with a documented specification and clean relational data migrates in half the time of one where PCG has to reconstruct both from scratch. The audit phase at the beginning of every PCG migration is what makes timeline estimates reliable rather than guesses.
- Source code available
- Original developer reachable for questions
- Clean relational database
- Single application module
- Staff who can demonstrate every workflow
- No source code, compiled executable only
- No documentation
- Multiple modules built by different developers
- Data spanning decades with inconsistent formats
- Undocumented edge cases in production
How does PCG scope a VB6 migration?
PCG does not quote VB6 migrations without an audit. The cost of any migration depends on the size of the application and how well it is documented. Data cleanup requirements are scoped during the audit. That figure reflects 31 years of doing this work, not an estimate built from a sales conversation.
The audit engagement produces a written scope document with a firm project quote. Clients who want a number before the audit are getting a guess. PCG does not give guesses on work that will run a business for the next 15 years.
The comparison that matters is not migration cost versus zero. It is migration cost versus what the next emergency failure costs when the VB6 application breaks on a machine that will not run the runtime, two days before a deadline that cannot move. Schedule a free 30-minute consultation at phxconsultants.com to start the conversation.2
What happens to our data during the migration?
Data integrity is treated as non-negotiable on every PCG migration. The process runs on a copy of production data, never on live data, until the parallel testing phase confirms the new system produces correct results. Every record count is verified before and after. Every calculation the old system performed is tested against the new system's output on real historical data.
VB6 applications frequently connect to Access databases or early SQL Server versions with denormalized schemas and inconsistent data types. Records that accumulated formatting quirks over decades of manual entry are cleaned during the migration process. PCG cleans and normalizes data during migration rather than carrying the same problems into the new platform. The new system starts with data that matches what the new schema expects.
Clients receive a data migration report that documents record counts by table, any records that required manual review or correction, and the transformation rules applied. That report stays with the project documentation permanently.
Your VB6 application will not run forever.
PCG has been migrating these systems since before most of them were considered legacy. Start with a free consultation and get a firm scope and quote.
Contact PCG NowFrequently Asked Questions
1 Microsoft Visual Basic 6.0 support lifecycle documentation. Microsoft ended mainstream support in 2005 and extended support in 2008. Runtime compatibility with Windows 11 is not guaranteed and has degraded with each major OS release since Windows 10 version 21H2.
2 PCG project data, 1995 to 2026. Emergency migration engagements triggered by system failure average 40% higher cost than planned migrations of equivalent scope.
Phoenix Consultants Group | phxconsultants.com | Founded 1995.
If your business software stopped working today, PCG can be on the phone with you within hours. We have been stabilizing and rebuilding broken software since 1995. Most emergency situations get an initial diagnosis within one business day. Your system gets stable first. The longer-term decision about what to do next comes after that.
🔴 What counts as a software emergency?
A software emergency is any situation where a broken or failing system is actively costing you money, blocking operations, or creating compliance exposure right now. It is not a feature request. It is not a slow system. It is the point where work has stopped, data is at risk, or a deadline cannot be met because the software is failing.
- Database corruption, missing records, or data that will not open
- Software that ran yesterday and is refusing to start today
- Developer who built the system is gone, unreachable, or out of business
- Critical process that only one person knew how to run, and that person left
- Windows update, server migration, or IT change that broke a working application
- Year-end, audit, or regulatory deadline in days and the reporting tool is down
- Access database throwing errors no one on staff can diagnose
- Legacy application running on a machine that just failed with no backup
The common thread is operational paralysis. When the software that runs a core part of your business stops working and there is no one to call, that is when PCG gets the phone call. In 2026, orphaned legacy systems and single-developer applications fail constantly. The developers who built them have retired, moved on, or are simply unavailable. PCG has been diagnosing exactly these situations for 31 years.
⏱ How fast can PCG actually respond?
PCG answers the phone. That is not a marketing line; it is how the business has operated since 1995. For genuine emergencies, the initial call happens same day or next business day. The diagnostic review of what is broken and what it will take to fix it is delivered within one to two business days depending on complexity.
Speed matters here, but so does accuracy. A wrong diagnosis in an emergency situation makes things worse. The first conversation is a triage call where PCG determines the severity, identifies what data is at risk, and establishes whether the system can be stabilized in place or needs to be bypassed immediately. That call takes 30 to 60 minutes and costs nothing.
For PCG-built applications, emergency response is even faster. Clients on a monthly support retainer get same-day response with full system access already established. Most issues on PCG-built software get resolved within hours, not days, because PCG has the source code and the institutional knowledge of exactly how the system was designed.1
🛠 What does the emergency response process actually look like?
PCG runs a structured emergency process that has been refined over decades of exactly these situations. The goal is to stop the bleeding first, then figure out what caused it.
30 to 60 minutes. PCG asks the questions that establish what is actually broken versus what appears broken. The failure mode matters. A database that will not open is different from one with corrupted records, which is different from a login that stopped working after a server change.
PCG reviews the application and the error logs. The database state is examined alongside the environment. For legacy systems with no documentation, this phase takes the most time. The diagnosis report identifies what is broken and whether data is at risk. Recovery options are laid out before any work begins.
Getting the system functional enough to operate while the longer-term fix is scoped. Not every emergency requires a full rebuild. Many situations can be stabilized in hours. PCG will tell you honestly which category your situation falls into before any work begins.
Once the immediate crisis is resolved, PCG delivers a written assessment of what happened and what was done. The options going forward are documented clearly. Some clients stabilize and stay. Others use the emergency as the moment to finally migrate off a system that has been fragile for years.
🔍 Can PCG fix software built by someone else?
Yes. The majority of emergency calls PCG receives are for software built by developers who are no longer available. This is one of the defining realities of custom software in 2026: a significant portion of the applications keeping businesses running were built by individual contractors, small shops, or in-house developers who are no longer around to support them.
PCG approaches these situations the same way a structural engineer approaches an older building with no blueprints. The work begins with understanding what the system does before touching anything. PCG reads the code and traces the data flows, building enough working knowledge of the system to diagnose it safely. Dependencies are mapped as part of that process. That process takes longer than working on PCG-built software, but it is not unusual work for this team.
The technologies that show up in most emergency calls are ones PCG has been working with for decades: Microsoft Access, Visual Basic 6, older ASP applications, Excel-based systems, and custom .NET applications of various ages. The 32-bit application running on a Windows 10 machine that just received an update is a familiar situation. So is the Access database that was last touched by a developer who retired in 2019.2
💰 How does PCG scope emergency software support work?
Every engagement starts with a free triage call. PCG will not quote a repair job without first understanding the system. Quoting emergency repair work without a proper diagnosis produces numbers that are either wildly high or dangerously low, and neither serves the client well.
After the triage call, PCG delivers a written diagnosis that identifies what is broken and what data is at risk. Repair options are scoped from that diagnosis with realistic timelines. The repair work is scoped and quoted from that diagnosis. Nothing starts until the scope and cost are agreed in writing.
Clients who move to a monthly support retainer after an emergency engagement eliminate the emergency call scenario entirely for PCG-managed systems. Every call gets answered. Issues get resolved before they become crises. Schedule a free 30-minute consultation at phxconsultants.com to get the conversation started.
⚠️ What if the system is too old or too broken to fix?
Some systems are genuinely not worth repairing. PCG will tell you that directly, and it happens more often than the industry admits. A VB6 application running on a 15-year-old server that just failed, with no source code and no documentation, and 40 percent database corruption, may not be recoverable in a way that makes financial sense.
When a system is beyond practical repair, the options are replacement or manual operation while a replacement is built. PCG scopes both. The replacement can be a modern .NET application built on PCG's FireFlight Data System or a migration to a platform that already exists in your industry. Which option makes sense depends on what the system does and how many people use it. Budget is scoped after the diagnostic.
The worst outcome is paying for emergency repairs on a system that fails again in six months. PCG will not take that work. If the only honest path forward is replacement, the diagnostic report says so clearly.
Your system is down. Call PCG.
The triage call is free. PCG answers the phone. Get the conversation started today.
Contact PCG NowFrequently Asked Questions
1 PCG internal support data. Response times for clients on monthly retainer agreements, April 2026.
2 Microsoft Windows 10 32-bit application compatibility documentation, Microsoft Support, 2025. Legacy software failure rates for applications built prior to 2010 are significantly higher on systems running Windows 10 version 22H2 and later.
Phoenix Consultants Group | phxconsultants.com | Founded 1995.
🚨 What does it mean when your developer disappears?
It happens in several ways. The freelancer who built your system stops responding. The small development shop closes. The internal IT person who maintained everything leaves the company and takes institutional knowledge with them. A vendor goes out of business or is acquired, and support for your system quietly ends.
In every case, the result is the same: you are running software that nobody currently available fully understands. The code exists. The data is there. The system still runs, for now. But nobody can fix it when something breaks, nobody can modify it when your business changes, and the longer it runs without maintenance the more fragile it becomes.
In 2026 this situation is more common than it was ten years ago. The generation of custom software built on Visual Basic 6 and older Access databases is aging. Early .NET applications from the same era face the same pressures. is aging. The developers who built those systems are retiring, moving on, or simply unreachable. PCG has been handling these rescues since before most of those platforms were considered legacy.
🔍 What are the warning signs your orphaned system is about to fail?
When the employee who understands the system's quirks leaves, the system effectively becomes unusable. If that knowledge is not documented, it is gone.
Software built for Windows XP, Server 2003, or 32-bit environments will eventually stop running as hardware is updated. Many businesses discover this during a routine upgrade.
If adding a field or changing a report requires careful manual workarounds, the system has reached the point where maintenance costs more than the work it saves.
A system that threw one error per month and now throws one per day is on a trajectory. Data corruption and rejected records accumulate silently. Calculation errors surface last, often after months of bad data.
If the developer left without transferring source code ownership, you may be running compiled software with no way to modify or migrate it. This is a critical risk that needs to be addressed before the system fails entirely.
No documentation means no new developer can understand what the system does without spending weeks reverse-engineering it. That time adds directly to the cost of any future rescue or rebuild.
🛠️ What should you do right now?
The sequence matters. The instinct when a system feels vulnerable is to rebuild it immediately. That is usually the wrong move. A rushed rebuild often replicates the same problems in a newer codebase. The right sequence is stabilize first, document second, then replace on your timeline rather than the system's timeline.
Source code, database files, documentation, any notes the previous developer left. If the developer is reachable, contact them now and request a full handover package. If they are not reachable, work with whoever has server access to pull what exists. Do not wait until the system breaks to discover what you do and do not have.
Every undocumented change to an orphaned system is a trap for the next developer. If something must change before a proper handover, document it in writing: what changed and when. The reason for the change belongs in that record too. A system that has been quietly patched for years without documentation is significantly harder and more expensive to rescue than one that has been left alone.
Before committing to a rebuild, a patch, or a migration, have someone who can read the code tell you what you actually have. PCG's diagnostic engagement does exactly this: we map what the system does, identify where it is fragile and assess the data. A written recommendation with a fixed-price proposal follows from that assessment. Schedule a free 30-minute consultation to start.
If the system is still running, the goal is to keep it running long enough to execute a controlled migration rather than an emergency one. Emergency migrations produce data loss and missed requirements. Rushed deployments create the next set of problems. A stabilized legacy system buys you the time to do the replacement correctly.
A system that is failing gives you no control. A system that is stabilized and documented gives you 6 to 12 months to plan and execute a proper replacement. That difference determines whether the new system is built correctly or built in a panic.
The communications dispatch system PCG rebuilt for an ambulance company came in as an emergency. The DOS-based system was actively failing and interfering with the company's ability to reach clients. PCG patched it to keep it running while rebuilding the replacement in parallel, deploying in modules to avoid a single risky cutover. The company kept operating throughout.
A separate data rescue project came in as a different kind of emergency: a vendor was holding a client's data after a failed CRM deployment. PCG negotiated the extraction, rebuilt the record linkages from a corrupt SQL Server dump, and migrated 400 member records to a new platform without loss. Neither situation required a panic rebuild. Both required a methodical approach that started with understanding exactly what existed before deciding what to do next.
💡 Can PCG reverse-engineer software the original developer left behind?
Yes. This is one of PCG's specific capabilities, developed across 31 years of working with legacy systems in industries where the original developer was long gone. The work involves reading the existing code, tracing how data moves through the system, identifying the business logic embedded in formulas and stored procedures, and producing documentation that did not previously exist.
That documentation becomes the foundation for whatever comes next, whether that is a patch, a migration to a modern platform, or a full rebuild. A system that was undocumented and understood by nobody becomes a system with a clear picture of what it does and what it costs to maintain. What replacing it would require is documented in the same report. That clarity is what makes a controlled decision possible instead of a forced one.
Frequently asked questions about orphaned software
Allison has been building and rescuing custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. Orphaned software rescue is one of PCG's core capabilities, developed across 31 years and 500+ projects in industries where a system failure is not an option. Every rescue starts with a diagnostic that maps what exists before recommending what to do next.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding. Project examples referenced on this page are drawn from PCG's documented project history.
What does "custom software" actually mean in 2026?
"Custom software" covers a wider category than most buyers expect. At the small end it is a focused application built on a configured platform, replacing one or two spreadsheets and serving a single team. At the large end it is a multi-location system with hardware integration, regulated reporting, and 50 or more concurrent users. Both projects are accurately called custom software. They have almost nothing else in common.
Because the category is wide, any quote you receive without a written scope behind it is a guess. A small project and a large project quoted the same way will both be wrong. The price you can actually plan around comes after the scope is documented, not before.
If a developer gives you a firm price in the first conversation, before mapping your current systems, that price is either padded heavily to absorb unknown scope, or it is going to grow once development begins. Neither is what you want.
What are the size categories PCG actually builds?
Small: focused deployment
Three to five configured modules on an existing platform. Single team or single workflow. Single decision-maker can approve. Typically 8 to 12 weeks from scope to go-live.
Mid: custom business application
Purpose-built application covering one or two connected workflows. Multi-user, role-based access, reporting, integrations with one or two external systems. Typically 12 to 20 weeks.
Large: multi-site enterprise
Multi-location architecture, hardware integration, legacy data migration, regulated audit trails, dozens of concurrent users. Typically 4 to 9 months. Requires a steering committee on the client side.
These categories cover the projects PCG has delivered across 31 years of custom software work, including the municipal fleet fueling system that ran 65 sites at go-live, the multi-facility physician staffing platform, and the ground support equipment management system for airport operations. The size of your project tells you which category you are in. The diagnostic tells you the price and the timeline.
What actually drives the cost up or down?
Four factors account for most of the variation between a small and a large project. Understanding them before you talk to a developer will make every conversation more productive.
Scope and number of modules. A system that handles scheduling, credentialing, payroll, invoicing, and mobile access costs more than one that handles scheduling only. Every module added to the scope adds development time. The most common cost overrun in custom software is scope that grows after work begins. A written scope before contract removes that risk.
Legacy data migration complexity. If your data currently lives in old Access databases, spreadsheets, or a system the original developer built and left undocumented, the migration work adds to the project cost. Clean data in a well-structured source moves fast. Fragmented data with no documentation takes significantly longer to reconcile, validate, and migrate without loss.
Number of users and locations. A system used by five people at one location is simpler to build and test than one used by 100 people across 30 sites. Multi-site architecture, role-based access across departments, and offline operation modes all add engineering work.
Hardware and third-party integrations. Software that connects to physical hardware (RFID readers, barcode scanners, specialized printers, tank monitors) costs more than software running on standard computers. Third-party API integrations with payroll systems, accounting platforms, or communication tools also add to scope.
Regulatory and compliance requirements. Systems that meet EPA reporting, OSHA documentation, or government audit requirements need additional security architecture, audit trail design, and output formatting1. That adds time and cost but protects the organization if it ever faces a regulatory review.
Timeline pressure. A project with a hard deadline that requires accelerated development or parallel work streams costs more than one with a standard timeline. The municipal fleet fueling system PCG delivered ran all sites simultaneously at go-live. That kind of coordination has a cost.
When does custom software make financial sense?
The question is not whether custom software is cheaper than off-the-shelf. On day one it usually is not. The real question is whether the off-the-shelf options actually solve the problem. For a significant number of businesses, the answer is no.
Off-the-shelf software is built for the average of its market. If your operation is average, it fits. If your compliance requirements are specific, your workflow is unusual, your data structure does not match what the product assumes, or you have already tried two or three platforms and none of them handled your actual process correctly, custom software stops being an expense. It becomes the only option that actually works.
Off-the-shelf SaaS
What you actually pay over 10 years
- Annual licensing fees that compound
- Per-seat pricing as your team grows
- Staff time on daily workarounds
- Data export costs when migrating off
- Replacement cost when the vendor changes terms
Custom application
What you actually pay over 10 years
- One-time development cost
- Predictable monthly support retainer
- Full ownership of your data, exportable at any time
- No per-seat penalty for growth
- System evolves with your operation, not the vendor's roadmap
For operations whose workflows do not map cleanly to any product on the market, the total cost of ownership math favors custom over a 5 to 10 year horizon. The custom system is built for your specific operation, and your data stays yours, exportable at any time. With off-the-shelf products you adapt your operation to the vendor's roadmap instead of the other way around.
How does PCG quote a project?
Every PCG engagement starts with a diagnostic. Allison maps the current system, documents what it does and where it fails, identifies the data that needs to move, and scopes what a replacement or new system would require. The diagnostic produces two things before any development begins: a fixed price you can take to your board, and a delivery timeline you can plan operations around.
Fixed-price means the number in the proposal is the number on the invoice. PCG does not bill by the hour on development work. If a project takes longer than estimated because of something on PCG's side, that is PCG's problem. If the scope changes because the client wants to add modules or features mid-project, that becomes a separate proposal with a separate price. Scope changes are the most common reason custom software projects go over budget. A fixed-price model makes scope creep visible before it becomes a surprise.
Roughly 40 percent of diagnostic engagements convert to a full deployment. The other 60 percent either decide the timing is not right, find that their existing system can be patched rather than replaced, or get a clearer picture of what they actually need before talking to other developers.
The diagnostic is worth doing regardless of what you decide afterward. You walk away with a documented scope, a price you can plan around, and a timeline that tells you when the system goes live. If you take that document to another developer, you can compare like-for-like quotes instead of guessing.
Get a real number for your project
A short diagnostic produces a written scope, a fixed price, and a delivery timeline. No development begins until both are agreed.
Frequently asked questions about custom software cost
Sources
1 U.S. Environmental Protection Agency, electronic reporting and recordkeeping requirements for regulated facilities. epa.gov/compliance
In 2026, Microsoft Access is not part of Microsoft's forward roadmap for enterprise data management. The ecosystem of developers who can maintain your system without introducing new risk is contracting every year. PCG has been migrating businesses off Access since 1995. The migration path is known, the data comes out intact, and the business does not stop while the new system is being built.1
Why are so many businesses still running Microsoft Access in 2026?
The answer is not ignorance. It is fear, and that fear is rational. Access databases tend to be deeply customized, lightly documented, and held together by logic that lives inside one person's head. The moment that person leaves, the entire operation becomes fragile. But the prospect of replacing it feels even more dangerous than keeping it. So businesses stay. They patch. They add workarounds. They hire the one consultant who knows the system.
This is the Access Trap, and it compounds every year you remain in it. The technical reality driving urgency in 2026 is straightforward: Microsoft 365 investments are concentrated in cloud-native tools, Power Platform, and SQL Server. Access receives maintenance updates, not innovation. The pool of developers who specialize in Access is contracting. The question is no longer whether to migrate. It is how to do it without breaking the business in the process.
How do I know if my Access database has crossed from workable to organizational liability?
The following indicators appear consistently in businesses where the Access system has passed its functional limit. If three or more describe your current environment, the database has become an organizational liability.
- The Single-Expert Dependency. Only one person, internal or external, fully understands how your database works. If they left tomorrow, you would not know where to begin.
- The Concurrent User Ceiling. More than four or five people trying to use the system simultaneously causes slowdowns, lockouts, or data corruption errors.
- The Manual Bridge Problem. Staff regularly export data from Access into Excel to perform calculations, create reports, or share information across departments, because Access cannot do it directly.
- The Integration Dead End. Your Access database cannot connect to your accounting software, your e-commerce platform, your warehouse system, or your CRM without a manual import/export process.
- The Audit Impossibility. When something goes wrong in your data, a duplicate record, a missing entry, a billing error, you have no reliable way to trace who changed what and when.
- The Backup Uncertainty. Your backup process for the Access .mdb or .accdb file is informal, undocumented, or depends on a single person remembering to run it.
- The Growth Ceiling. You have held back from scaling a product line, a location, or a team because you know the current system cannot handle the additional volume.
What does staying on Access actually cost per year in operational terms?
The weekly manual friction figures in the table below are not abstractions.2 They represent your operations manager spending Sunday evening reconciling records. They are your accountant re-entering invoices because the export broke. They are your warehouse team running on printed reports because no one can pull live data from the system.
| Operational State | Weekly Manual Friction (Hours) | Annual Data Risk Exposure | Scalability Ceiling |
|---|---|---|---|
| Legacy Access: Single-User or Small Team | 15–25 hrs | High: corruption risk, no row-level audit trail | Hard ceiling at current volume |
| Access with Manual Excel Bridges | 30–40 hrs | Very High: dual-entry errors, no single source of truth | Cannot scale without adding headcount |
| FireFlight Migration (PCG Framework) | < 3 hrs | Near-Zero: transactional integrity, full audit trail | Engineered for 10x current volume |
That friction has a dollar value. In most Access-dependent organizations PCG engages, the annual cost of manual workarounds sits between 8% and 14% of total operational labor cost. A business with 15 employees spending an average of 5 hours per week each on Access-driven workarounds, at a blended rate of $30 per hour, absorbs $117,000 per year in invisible operational cost before any direct database expense is counted.
Why is FireFlight the right destination for businesses migrating off Access?
Access stores data in a single file. That architecture made sense for a desktop tool in 1995. In a multi-user, multi-location, real-time business environment, it creates a structural fragility that no amount of patching can fix. The file becomes the single point of failure. Every user who opens it adds risk. Every external connection is a workaround built on top of an architecture that was not designed for it.
FireFlight operates on a fundamentally different model. The data lives in a structured, relational SQL engine. Business logic is separated from the data layer. User interfaces are built independently of the database structure, which means they can be modified, extended, or replaced without touching the underlying records. Reporting is real-time, not a snapshot from last night's export. For businesses migrating from Access, this is not a theoretical upgrade. It is a structural correction.
- Data Preservation. Every record, every relationship, every historical transaction migrates intact. PCG's migration process does not lose data. It restructures it into a framework that can actually use it at the volume and speed your business now requires.
- Logic Translation. The business rules embedded in your Access forms, queries, and VBA code do not disappear. They are analyzed, documented, and re-engineered in FireFlight's architecture, often surfacing process improvements that were invisible inside the Access environment.
- Familiar Workflows, Modern Infrastructure. PCG designs the FireFlight front end to reflect how your people actually work, which reduces training time and resistance to adoption. Your team is not learning a foreign interface. They are using a more reliable version of the process they already know.
What does the actual Access migration process look like, and what happens to operations during it?
The fear that stops most Access-dependent businesses from migrating is the same one every time: what happens to the business while the system is being replaced? When migration is managed correctly, the answer is that nothing stops.
PCG maps every table, every query, every form, every report, and every VBA module in your existing Access environment. The business logic is documented, including the logic that is not written down anywhere because it only exists in one person's institutional memory. The output is a complete blueprint of what your system actually does, as opposed to what it was originally designed to do. This phase often surfaces undocumented process logic that would have been lost in a migration without it.
FireFlight is built alongside your existing Access system, not in place of it. Your team continues operating on Access throughout this phase. PCG builds, tests, and validates the new system against live data without interrupting any operational process. The migration does not replace anything until the replacement has been confirmed to work correctly against the actual data your business generates every day.
When FireFlight is confirmed to match or exceed the functional coverage of your Access system through parallel testing, the cutover is executed in a defined operational window. Business operations transfer to the new system within that window. Access remains available in read-only mode for a transition period as a reference baseline. The business does not stop. The risk is managed. The new system is live from day one of cutover.
What experience backs PCG's Microsoft Access migration methodology?
Allison Woolbert began programming in 1983 and has been working in Microsoft Access since 1995, thirty years of production-level engagement with the platform. That is not a credential listed on a website. It is operational fluency built across three decades of real engagements: custom databases for healthcare operations, logistics companies, professional service firms, government contractors, and manufacturing businesses that all built their operations in Access and then needed to migrate without losing what they built.
PCG was founded in 1995. In 31 years, the firm has operated as a specialist in custom systems and data architecture, and it was recognized early as a migration specialist precisely because of this combination: deep legacy knowledge and a modern architectural framework built specifically to receive that knowledge at enterprise scale. The FireFlight Data Framework was developed directly from Allison's experience identifying the structural limitations that Access imposes on growing businesses, and engineering the path out.
1 Microsoft Access forward roadmap position sourced from: Microsoft 365 product lifecycle documentation (2024); Microsoft Ignite 2024 enterprise data strategy announcements; Gartner Data Management Hype Cycle 2024.
2 Weekly friction hour ranges and annual labor cost percentages (8%–14%) based on PCG pre-migration assessments across 12 Access-dependent organizations, 2019–2025; corroborated by Aberdeen Group Legacy System Operational Cost Research 2024.
Frequently Asked Questions
Allison began programming in 1983 and has been working in Microsoft Access since 1995, thirty years of production-level engagement with the platform across healthcare operations, logistics companies, professional service firms, government contractors, and manufacturing businesses. Her work spans custom Access builds, architectural rescues of abandoned databases, and full migrations to modern SQL Server platforms.
PCG was founded in 1995 and has operated for 31 years as a specialist in custom systems and data architecture. The FireFlight Data Framework was developed directly from Allison's experience identifying the structural limitations that Access imposes on growing businesses, and engineering a migration path that preserves everything the business built while removing the constraints that are holding it back.
Phoenix Consultants Group is a Minority Women and Veteran Owned business based in the United States.
In 2026, businesses still running Sage 50, Sage 100, Dynamics GP, or Peachtree are not running them because they are good choices. They are running them because migration feels more dangerous than staying. The Friction Tax on a legacy ERP typically runs 10% to 18% of annual operational labor cost, every week, without appearing on any report.1 PCG has migrated businesses off these platforms for 31 years. The path is known.
Why do Sage, Great Plains, and Peachtree become operational traps over time?
The pattern is consistent across industries. A business implements one of these platforms during a period of rapid growth when it needs structure. The implementation is customized: reports built to spec, workflows adjusted, integrations patched together with middleware or manual processes. Over time, the system becomes load-bearing in ways that were never formally documented.
The compounding then begins. The vendor raises annual support costs. The consultant who knew the customizations retires or moves on. A new version of Windows introduces compatibility issues. The integration with the shipping system breaks and no one knows exactly why. The controller builds a parallel Excel workbook because pulling the report she needs from the ERP takes 45 minutes and three manual steps.
None of these are catastrophic events individually. Together, they represent a system consuming operational energy faster than it is producing operational value. PCG calls this the Friction Tax: the cumulative cost of working around a system rather than working with it. In legacy ERP environments, the Friction Tax typically runs between 10% and 18% of annual operational labor cost. It does not appear on any report. It is simply the price the business pays, every week, for not having made the move.
The vendors have made their position clear through their actions. Sage has repeatedly restructured its product lineup, discontinuing versions and raising support costs on legacy installations. Microsoft ended mainstream support for Dynamics GP and has directed its roadmap toward Dynamics 365, a platform that requires a fundamentally different implementation and licensing model. Peachtree, absorbed into Sage years ago, continues to age without meaningful architectural investment.
How do I know if my legacy ERP has crossed from aging system to operational risk?
The following indicators appear consistently across manufacturing, transportation, healthcare, and industrial operations that PCG has engaged. If four or more of these describe your current environment, the ERP has crossed that line.
- Vendor Uncertainty. Your ERP vendor has announced end-of-life, restructured its support tiers, or directed you toward a cloud migration that does not map cleanly to how your business actually operates.
- The Customization Wall. Your implementation is so customized that standard upgrades break functionality. Every version update requires a separate consulting engagement to assess compatibility before it can be applied.
- The Report Lag. Generating an accurate operational report, whether inventory position, job cost, or production status, requires a long system query, a manual export to Excel, or both. Real-time visibility does not exist.
- The Integration Dead Zone. Your ERP does not talk directly to your warehouse system, your CRM, your e-commerce platform, or your shipping carrier. Every data transfer is a manual or semi-automated bridge that introduces error and delay.
- The Compliance Pressure. Your industry's regulatory reporting requirements have evolved, whether OSHA, EPA, healthcare credentialing, or DOT, and your ERP cannot generate the required documentation without significant manual assembly.
- The Single-Expert Risk. One person, internal or external, is the functional administrator of your ERP. That person's departure would leave the organization unable to manage the system without emergency external support.
- The Scalability Signal. You have held back from adding a product line, opening a second location, or expanding a service offering because you know the current system cannot support the additional operational complexity.
What does staying on a legacy ERP actually cost per year?
The weekly friction hours in the table below are not theoretical.2 They represent your production manager pulling data manually because the system report does not reflect current inventory. They are your accounting team re-entering transactions because the ERP integration with your bank broke two software versions ago. They are your compliance officer assembling regulatory reports from four different exports because the ERP was not built for the reporting standard your industry now requires.
| Operational State | Weekly Friction Hours | Annual Friction Tax (Labor Cost %) | Scalability Ceiling |
|---|---|---|---|
| Legacy ERP: Standard Installation | 20–30 hrs | 8%–12% | Hard ceiling at current configuration |
| Legacy ERP: Heavily Customized | 35–50 hrs | 12%–18% | Cannot upgrade without breaking customizations |
| Legacy ERP: End-of-Vendor-Support | 40–60 hrs | 15%–22% | Active risk: no security patches, no compliance updates |
| FireFlight Migration (PCG Framework) | < 4 hrs | < 1% | Engineered for 10x current operational volume |
That friction has a dollar value. Unlike capital expenditure, it recurs every week without appearing on any budget line. A business with 20 employees spending an average of 6 hours per week each on ERP-driven workarounds, at a blended labor rate of $35 per hour, is absorbing $218,400 per year in invisible operational cost before a single line-item of direct ERP expense is counted.
Which industries feel legacy ERP pain most acutely in 2026?
PCG has worked across manufacturing, transportation, healthcare, industrial safety, regulation compliance, and law enforcement operations. In each sector, the legacy ERP failure pattern has specific characteristics worth naming directly.
Manufacturing and Industrial Operations
Sage 100 and Dynamics GP were designed for a manufacturing environment that did not include real-time floor data, multi-location inventory visibility, or IoT integration. Job costing, bill of materials management, and production scheduling are where legacy ERPs show their age first in manufacturing operations that have grown beyond a single production facility.
Transportation and Logistics
Shipping container tracking, fleet management, driver compliance, and DOT regulatory reporting are not functions that legacy ERPs handle natively. Most transportation operations PCG has engaged run a patchwork of the ERP, a separate dispatch system, a spreadsheet compliance tracker, and a manual reporting process. That patchwork is where data integrity fails and regulatory exposure accumulates.
Healthcare and Residential Care
Credentialing, scheduling, payroll integration, and HIPAA-compliant data handling are requirements that standard Sage or Great Plains installations were never designed to meet. Healthcare organizations running legacy ERPs almost always have a parallel specialized platform that does not integrate with the ERP, producing two sources of truth where neither is fully reliable.
Regulation Compliance and Environmental Operations
EPA reporting, OSHA training records, material safety data, and pesticide licensing compliance require documentation trails that legacy ERPs cannot produce without significant manual assembly. The compliance exposure in these environments is not operational friction. It is regulatory risk with measurable financial consequences and no statute of limitations on historical gaps.
Why is FireFlight a different kind of destination than moving to NetSuite or a newer Sage?
The standard advice when a business outgrows a legacy ERP is to migrate to another packaged platform: a newer version of Sage, a move to NetSuite, a Dynamics 365 implementation. Each of these options replaces one set of constraints with a different set. The business adapts its operations to fit the new software, pays implementation and licensing costs, and begins the same compounding cycle on a newer timeline.
FireFlight is not a packaged ERP. It is a custom-engineered data architecture designed around the specific operational logic of the business it serves, built on a SQL Server backbone with separated data, logic, and interface layers that can be extended independently as the business evolves.
- No Feature Compromise. The functionality your business depends on, including the customizations built into your current Sage or Great Plains installation, is re-engineered into FireFlight's architecture. You do not lose functionality to fit the platform. The platform is built to fit your functionality.
- No Licensing Dependency. FireFlight is not a subscription. The architecture PCG builds is owned by the business. There is no vendor roadmap that can obsolete your investment, no annual license increase, no forced migration to a cloud platform you did not choose.
- Real-Time Operational Visibility. FireFlight provides live data access across every function without the export-and-reconcile cycle that legacy ERP reporting requires. Decisions are made on data from the last 60 seconds, not the last 14 days.
- Designed Integration Architecture. The integration layer is part of the core architecture, not a patch or a middleware workaround. Your warehouse system, shipping platform, compliance tools, and financial systems connect through designed integration points, not manual bridges.
What does the actual migration process look like, and what happens to our operations during it?
The question PCG hears most consistently from executives considering a legacy ERP migration is the same one, asked in different ways: what happens to the business while the system is being replaced? In the PCG migration methodology, operations continue without interruption throughout the entire process.
PCG maps the existing ERP environment completely: every module in use, every customization, every integration, every report that operations depends on. This includes the undocumented logic: the workarounds built into the system over years, the Excel bridges, the manual processes that exist because the ERP cannot do something directly. The output of this phase is a complete functional specification of what the business actually needs, as distinct from what the current system was originally designed to provide.
FireFlight is constructed alongside the existing ERP. The legacy system continues to run all operational functions throughout this phase. PCG builds, tests, and validates FireFlight against live operational data, including stress testing for the volume and complexity the business actually generates. No operational decision is made on FireFlight data until it has been validated to match the reliability of the legacy system in every functional area.
When FireFlight validation is complete, the cutover is executed in a defined operational window, typically a weekend or a planned low-volume period. The legacy ERP remains available in read-only mode for a defined transition period as a reference baseline. Business operations run on FireFlight from cutover day forward. The business does not stop. The data does not disappear. The operational logic does not get lost in translation.
What experience backs PCG's legacy ERP migration methodology?
PCG has built custom systems for manufacturing operations, transportation fleets, healthcare facilities, environmental compliance programs, law enforcement agencies, and industrial safety operations since 1995. That cross-industry depth is the foundation of PCG's ability to design a migration architecture that reflects how a specific business actually operates, rather than how a software vendor assumes it operates.
Allison Woolbert began programming in 1983. She has been designing custom database and enterprise system architectures for over 40 years, including engagements with organizations where operational continuity, data integrity, and regulatory compliance are not preferences but requirements. The FireFlight Data Framework was designed from that experience: a system built to handle the complexity that packaged platforms cannot accommodate and the scale that legacy systems cannot sustain.
In 31 years, PCG has not sold a software license. Every engagement is a custom architecture built for a specific business, and that architecture belongs to the business, not to PCG.
1 Friction Tax range (10%–18% of annual operational labor cost) derived from PCG Legacy System Audit assessments across 14 manufacturing, healthcare, and industrial operations, 2019–2025; corroborated by Aberdeen Group ERP Operational Efficiency Research 2024.
2 Weekly friction hour ranges and annual labor cost percentages based on PCG client pre-migration assessments; end-of-support risk classification aligned with Microsoft Dynamics GP end-of-mainstream-support announcement (September 2025) and Sage product lifecycle documentation.
Frequently Asked Questions
Allison began programming in 1983 and has spent over 40 years designing custom database and enterprise system architectures across manufacturing, healthcare, transportation, industrial safety, regulation compliance, and law enforcement operations. Her work spans engagements where operational continuity, data integrity, and regulatory compliance are not preferences but requirements.
PCG was founded in 1995. In 31 years, the firm has not sold a software license. Every engagement is a custom architecture built for a specific business, and that architecture belongs to the business, not to PCG. The FireFlight Data System is PCG's purpose-built answer to the structural limitations of legacy ERP platforms.
Phoenix Consultants Group is a Minority Women and Veteran Owned business based in the United States.
In 2026, the maintenance burden of a heavily patched legacy system grows every quarter. Each patch solves one problem and introduces conflict points with the patches that came before it. PCG breaks this cycle by replacing fragmented legacy architecture with FireFlight Data System: a clean-sheet, modular engine where maintenance overhead stays flat and the compounding cost of patch debt is eliminated permanently.
Why does every patch make a legacy system more fragile, not less?
Technical debt rarely announces itself as a crisis. It accumulates gradually, one justified shortcut at a time. A developer applies a targeted code fix to solve an urgent production issue rather than addressing the underlying database flaw, because the correct architectural fix would take two weeks and the business needs a resolution today. A third-party plugin extends a function the original system was never designed to handle. A custom integration bridges two systems that were never meant to communicate.
Each of these decisions is individually defensible. Collectively, they produce a system where layers of patch logic conflict with each other in ways no single person fully understands, where every update to one component carries an unpredictable risk of breaking three others, and where the processing overhead of navigating years of redundant, conflicting code slows every transaction the system handles. At this point, the organization is not maintaining a system. It is servicing a liability. The IT budget is not buying capability. It is paying a maintenance tax to prevent a collapse that becomes more probable with every passing quarter.
There is a security dimension to this that rarely appears in technical debt discussions. Legacy systems running on outdated encryption standards, with no meaningful audit trails and no access controls that reflect current security requirements, carry exposure that compounds alongside the maintenance burden. Every patch added to keep the system running introduces another entry point that was never part of the original security design. The system is not just expensive to maintain. It is increasingly difficult to defend.
How do I know how much technical debt my system has actually accumulated?
The following table maps the operational trajectory of a system as technical debt accumulates over time, benchmarked against the FireFlight clean-sheet architecture. The progression is not linear: maintenance friction and failure risk compound as the number of conflict points between patches increases.1
| System State | Weekly IT Friction (Hrs on Maintenance) | Operational Consequence | System Failure Risk |
|---|---|---|---|
| 10+ Year Debt Overload: Critical patch dependency | 20-35 hrs/week | IT team cannot safely apply updates. Every change is a risk event. New capabilities require months of custom work. | Critical: any update is a potential collapse |
| 7-Year Frankenstein: Multiple conflicting patches | 12-20 hrs/week | Frequent bugs and integration failures. Staff build manual workarounds to avoid triggering known conflict points. | High: frequent bugs and integration failures |
| 3-Year Legacy: Early patch accumulation | 5-10 hrs/week | Manageable now but accelerating. Each new integration adds risk. The maintenance curve has begun to steepen. | Moderate: manageable but accelerating |
| FireFlight Clean-Sheet: Unified modular architecture | Under 2 hrs/week | New modules extend the system without modifying existing components. Maintenance overhead stays flat as the system grows. | Near zero: no patch conflict points |
The progression from 3-Year Legacy to 10+ Year Debt Overload is not a hypothetical trajectory. It is the documented operational reality of every organization that has deferred architectural replacement in favor of continued patching. The maintenance friction does not plateau. The failure risk does not stabilize. Both compound until the cost of continued patching exceeds the cost of replacement, at which point the organization typically faces a forced migration under crisis conditions rather than a planned clean-sheet transition.
What are the three signs that technical debt has become structurally dangerous?
Your IT team advises against applying a vendor update, not because the update is unnecessary, but because they cannot predict which other components will break when it is applied. This is the clearest single indicator of advanced technical debt: a system so interconnected through layers of patch logic that no one can safely change any part of it. A system your team is afraid to update is a system your organization no longer controls.
Adding a new capability, whether a new reporting tool, a new departmental function, or a new data connection, requires months of development work because every addition must be carefully threaded through the existing patch architecture without triggering a conflict cascade. In a clean-sheet system, new modules extend the existing core. In a heavily patched system, every new addition is another layer of debt laid on top of the ones already there.
The developer or IT manager who built the original system and who alone understands the logic underlying the most critical patches has left the organization, is planning to retire, or is the single point of failure for every system incident. When institutional knowledge is the only documentation your architecture has, your system's operational continuity and your key-man dependency have become the same problem. If this marker applies, address the personnel risk alongside the architectural one.
Why does adding modules to a fragmented system make technical debt worse, not better?
Generic ERP vendors respond to technical debt by selling additional modules: new layers of functionality added on top of the existing architecture. This approach does not resolve the structural problem. It compounds it. Every new module added to a fragmented system is another potential conflict point, another integration to maintain, and another dependency that makes the eventual replacement more complex and expensive.
PCG takes the opposite architectural position. FireFlight is built on a single, clean codebase: .NET Core 8 with Razor Pages, backed by a SQL Server architecture engineered for long-term performance stability. There are no patches in the FireFlight model because the system is modular by design. Every functional component is built as a self-contained module that communicates with the shared core database through standardized interfaces, not through custom integration logic. When a module needs to be updated or replaced, it is updated or replaced in isolation without risk of cascading failure to adjacent modules, because there is no patch logic connecting them.
This modular architecture is the structural mechanism that prevents FireFlight from accumulating its own technical debt over time. New capabilities are added as new modules that extend the existing system. The core database architecture remains clean. The codebase remains navigable by any qualified .NET developer, not just the person who wrote the original patches. The maintenance overhead does not compound. It stays flat, and in many cases declines as the system matures and the module library grows.
The starting point is a free 30-minute consultation. PCG maps where your system stands, what the migration to a clean-sheet architecture would require, and whether the timing makes sense for your operation. No commitment required at that stage.
Schedule Your Free ConsultationWhat does migrating from a patched legacy system to FireFlight actually look like?
PCG conducts a structured analysis of your current system architecture, mapping every patch, every third-party integration, every custom workaround, and every dependency between components. This audit produces a complete inventory of your technical debt: which patches are creating the highest risk, which integrations are the most brittle, and which components are safe to migrate first. The audit also identifies the essential business logic embedded in your existing code, the rules, validations, and workflow logic your operation depends on, which must be preserved and migrated to the new architecture, not discarded. This phase typically takes two to three weeks.
PCG engineers extract the essential business logic from your legacy system and re-encode it natively in FireFlight, not as a patch or integration, but as a first-class module built on the clean architecture. This is the most technically demanding phase of the migration and the one that determines whether the new system actually reflects the operational reality of your business. PCG executes this phase in parallel with your live system: FireFlight is built and validated against your current operational data while your existing system continues running. Your team tests the new system against real-world scenarios before any cutover decision is made.
Once FireFlight has been validated against your live operational data and your team is confident in its accuracy, the legacy system is retired in a controlled, sequenced cutover. PCG manages the final data migration, cleaning, mapping, and importing your historical records into the new architecture so they are more accessible and more useful in FireFlight than they were in the system being replaced. The legacy patches are gone. The maintenance overhead is eliminated. The new system starts clean, and the modular architecture ensures it stays that way. Most migrations complete in 8 to 16 weeks from audit to go-live.
What experience backs the FireFlight clean-sheet methodology?
PCG built FireFlight because the pattern of technical debt accumulation is not unique to any industry or organization size. It is the predictable outcome of any architecture that prioritizes speed over structural integrity. Allison Woolbert developed the clean-sheet methodology after more than four decades of working with organizations that had reached the point where their technology was more fragile than the business problems it was supposed to solve, including enterprise systems for ExxonMobil, Nabisco, and AXA Financial where architectural instability carries consequences that extend well beyond IT budgets.
In delivering the secure, scalable fueling management system for a Top-5 U.S. metro fleet, PCG replaced a legacy infrastructure that could no longer be safely modified or extended. Every operational requirement of the previous system was preserved while its architectural debt was eliminated entirely. The result was a system built on a modern, maintainable foundation that the client's team can extend, audit, and operate without depending on the institutional knowledge of the developers who built it. That is the standard PCG applies to every clean-sheet engagement.
1 Weekly IT friction hours derived from PCG Technical Debt Audit assessments conducted across 11 mid-market legacy system environments, 2021-2025; validated against Optifai Sales Ops Benchmark Report 2025 (N=687 companies).