When the source code for business software is lost, the cost falls into four categories that compound over time: operational disruption when the system finally fails, the migration premium paid for emergency timelines, business continuity exposure during unplanned downtime, and the long-term erosion of institutional knowledge. Total financial impact depends on how long the exposure remains unaddressed.
Source code loss rarely arrives as a single event. It accumulates quietly across years of staff turnover, vendor transitions, lost backup tapes, and undocumented contractor work. By the time a CFO becomes aware of the exposure, the business is often already running production software that nobody on the current team can modify, audit, or recover from a major failure. This article presents a financial framework for evaluating that exposure before the system fails, when the cost of action is still controllable.
Phoenix Consultants Group has been recovering orphaned business software since 1995, across more than 500 production engagements covering Microsoft Access, Visual FoxPro, Visual Basic 6, Delphi, PowerBuilder, and early .NET applications.1 The categories below come from that engagement history and reflect the financial patterns CFOs encounter when source code recovery becomes urgent rather than planned. This framework is platform-agnostic, so the financial mechanics apply equally to any custom business software in production.
What does "source code is lost" actually mean for a business in 2026?
Source code loss is a spectrum, not a single condition. A CFO assessing exposure should understand which point on the spectrum applies to the business, because the financial implications differ at each point. Four scenarios recur across PCG engagements, ordered from least to most severe.
Source code exists, knowledge does not
The source files are accessible on company servers, but nobody on staff or in any active vendor relationship can productively read them. Financial exposure: moderate, recoverable through a documented application audit.
Source code exists, location is unknown
The source files were preserved somewhere by a former developer or vendor, but the current team cannot locate them. Financial exposure: elevated, requires source recovery work before assessment is possible.
Partial source code only
Some source files are recoverable but others are missing, often the most recently modified ones. Financial exposure: high, requires reconstruction of missing components alongside recovered material.
Compiled application only
Only the executable and the database remain. No source files can be located anywhere. Financial exposure: highest, requires reverse-engineering from the compiled application and the data structure.
The framework that follows applies across all four scenarios. Cost mechanics, however, scale with severity. A CFO who identifies the scenario early has significantly more options than a CFO who discovers the exposure during a production failure. Early identification preserves the planning window in which exposure can be quantified, recovery can be scoped, and budget allocation can occur on a deliberate schedule.2
What is the cost of operational disruption when the software finally fails?
The first cost category is operational disruption. Line items appear immediately and continue accruing until the business resumes normal operations. CFOs typically focus on direct staff productivity loss, which is the most visible component, but operational disruption includes several other measurable expenses that surface only after the failure begins.
Staff productivity loss is the headline figure. When the system that runs accounting, inventory, customer records, or compliance reporting becomes unavailable, the staff who depended on it cannot perform their normal work. Some shift to manual workarounds using spreadsheets and paper forms. Others wait. The cost is the fully-loaded labor expense for the affected staff during the entire disruption window, less any productive work they manage to complete through alternative means.
Customer-facing impact follows quickly when the affected software touches the customer experience. Order intake delayed by manual workarounds. Customer service responses extended because the agent cannot look up account history. Invoices delayed because the billing system is the affected platform. Each touchpoint absorbs a measurable cost in delayed revenue, customer service overhead, and reputational impact that compounds across the disruption window.
Downstream system failures are the cost category most often underestimated. Modern business software rarely operates in isolation. The affected application typically feeds data to accounting, reporting, regulatory submission, or partner integration platforms. When the source system fails, the downstream systems begin producing stale or incomplete output. The cost is the staff time required to identify, correct, and restore confidence in every downstream data flow after the source system returns.2
How does emergency-timeline migration cost compare to planned migration?
The second cost category is the emergency migration premium. A migration triggered by a production failure runs on whatever schedule the broken business can survive, against whatever vendor the business can engage on short notice, with whatever scope the business can articulate during emergency conditions. Each of those constraints translates into measurable additional cost compared to a planned migration of the same application.
Timeline compression is the largest premium driver. A planned migration spreads discovery, design, build, and cutover across a comfortable window that allows for testing, validation, and operational learning. An emergency migration compresses the same work into whatever window the business can survive without the original software. Compression typically requires additional engineering hours to maintain quality under reduced timeline, premium rates for accelerated turnaround, and additional risk reserves to handle issues that surface late in the compressed schedule.
Vendor selection power disappears when the business is in emergency mode. A planned migration allows the CFO to evaluate multiple vendor proposals, negotiate scope, and select the engagement that produces the best long-term value. An emergency migration eliminates that negotiating position. The business engages whichever qualified vendor can start immediately, at whatever rate that vendor proposes, with whatever scope the vendor is willing to commit to under the time constraint. Price differences between selected-vendor and available-vendor often exceed the difference between planned-timeline and emergency-timeline considered alone.
Scope inflation is the third driver. A planned migration begins with a documented source application inventory that defines exactly what must be replicated in the destination system. An emergency migration begins without that inventory, because the business has not had time to build it. The vendor is forced to estimate scope against incomplete information, which produces either an inflated estimate to cover unknowns or an underscoped commitment that requires expensive change orders during execution. Either outcome costs more than a planned migration with documented scope.3
The emergency premium is not a small percentage adjustment. Across PCG engagements, an emergency migration consistently costs significantly more than the same scope executed on a planned timeline, before counting the operational disruption cost incurred during the emergency window. The decision to delay assessment is the decision to pay the premium.
What is the business continuity exposure during unplanned downtime?
The third cost category is business continuity exposure during the downtime window itself. Operational disruption captures the staff and customer impact. Business continuity exposure captures the broader financial risks that surface when revenue, compliance, or regulatory obligations depend on the affected software.
Revenue at risk is the most measurable component. When the affected software is part of the revenue process, every hour of downtime carries a quantifiable opportunity cost. Manufacturing operations that cannot produce. Service businesses that cannot bill. Retail operations that cannot transact. The cost is the gross revenue normally generated during the affected window, less whatever portion the business successfully recovers through workarounds or post-recovery batch processing.
Compliance and regulatory exposure carries the highest tail risk. Industries operating under regulatory schedules, such as environmental remediation, OSHA reporting, ISO 9000 documentation, or industry-specific compliance frameworks, face penalty exposure when the supporting software fails during a reporting window. The cost includes any penalties assessed, the staff time required to demonstrate good-faith compliance during recovery, and in severe cases the cost of external counsel or regulatory negotiation.4
Audit failure is the related risk that surfaces during external review rather than regulatory deadline. A financial audit, a quality systems audit, an insurance audit, or a customer audit conducted while the affected software is unavailable produces findings that can extend significantly beyond the original audit scope. Auditors who encounter undocumented systems often expand the scope of their review to validate adjacent business processes, which carries its own cost in staff time and potential remediation findings.
What is the long-term cost of lost institutional knowledge?
The fourth cost category is institutional knowledge erosion. This category accrues continuously, not at the point of system failure, which makes it the easiest cost to underestimate in advance and the most disruptive cost to address after the fact. Three components compose institutional knowledge erosion.
Undocumented business rules are the first component. Custom business software accumulates rules over years of development: pricing calculations, approval workflows, validation logic, regulatory mappings, and workflow conditionals that reflect how the business actually operates. When the original developer leaves and the source code is lost, those rules exist only inside the compiled application. The business operates on rules nobody on staff can articulate, which means decisions that depend on those rules cannot be reviewed, updated, or audited without rebuilding the rule logic from scratch.
Training cost is the second component. New staff who join the team after the institutional knowledge is lost must learn the system entirely from its observable behavior, without access to documentation that explains why the system behaves as it does. Onboarding timelines extend accordingly. The risk of staff making decisions based on incorrect mental models of the software increases. Each new hire carries a higher onboarding cost than they would in an organization with documented systems.
Decision lag is the third component, and the one most directly measurable in CFO terms. When a business question depends on understanding what the software actually does, and nobody on staff can answer the question definitively, decisions either delay until investigation completes or proceed against incomplete information. Both outcomes carry cost. Pricing decisions made on misunderstood logic. Capacity planning based on incorrect assumptions about system limits. Compliance reporting that cannot be defended under audit because the underlying calculations cannot be explained.2
Speak directly with the engineer who would scope your exposure assessment
A free 30-minute consultation to evaluate which of the four cost categories apply to your situation. No obligation, no sales handoff.
What hidden financial risks do CFOs underestimate?
Beyond the four primary cost categories, three secondary risks recur across CFO engagements. Each one is invisible until it triggers, and each one can equal or exceed the primary cost categories in financial impact when it surfaces.
The first hidden risk is integration cascade failure. Affected software typically connects to other systems through APIs, scheduled data transfers, or shared databases. When the affected software fails, the integration connections fail with it. Each connected system then begins producing incorrect output, missing updates, or accumulating queued transactions that cannot process. The cost of restoring confidence in every downstream system after the primary failure resolves often exceeds the cost of the primary recovery itself.
The second hidden risk is vendor concentration. CFOs who have not assessed source code exposure often discover that a single former vendor or contractor was responsible for multiple business-critical applications. When one of those applications fails and recovery is needed, the same exposure profile applies to every other application that vendor built. A single recovery engagement may surface the need for parallel recoveries across the rest of the portfolio, each carrying its own cost.
The third hidden risk is talent market exposure. Pools of developers qualified to work on legacy platforms shrink every year. CFOs who plan to address source code exposure "eventually" face a continuously degrading talent market for the platforms in question. The same recovery engagement scoped today costs more next year, and significantly more in five years, simply because the developer talent capable of executing it becomes scarcer over time.1
How can a CFO quantify exposure before the system fails?
The exposure assessment is a defined engagement, not an open-ended investigation. PCG performs source code and application inventory assessments designed specifically to produce a CFO-grade financial exposure document. Each deliverable is a written report mapping operational functions to the cost categories described above, with the exposure level identified for each function.
Assessment phase work typically completes in 2 to 4 weeks for a mid-sized business application. PCG works against copies of the source code, the compiled application, and the production database. Production systems continue operating normally throughout the assessment. The deliverable stands on its own as a planning document, regardless of whether the business subsequently chooses to proceed with source recovery, migration, or continued operation under the existing application.3
Without an exposure assessment
CFO operates on assumption
- Total financial exposure unknown
- Cost categories not separated by operational function
- Vendor concentration risk undocumented
- Recovery cost can only be estimated after system failure
- Budget planning happens reactively, under timeline pressure
- Compliance and audit exposure unquantified
After the exposure assessment
CFO has a planning document
- Written exposure profile organized by business function
- Cost categories quantified for the specific application
- Vendor concentration risk mapped across the portfolio
- Recovery engagement scope and timeline documented
- Budget allocation can happen on a planned schedule
- Compliance and audit exposure included in the assessment
A planned exposure assessment costs measurably less than the operational disruption of a single production failure. CFOs who have completed the assessment own a planning document the business uses regardless of next steps.
PCG's exposure assessment connects naturally to subsequent engagements when the business chooses to proceed. Recovery work begins with the inventory already in hand. Migration scoping begins with the financial categories already documented. A continued-operation path also becomes possible because the business now has the documentation it never previously had. The assessment is the foundation, not a commitment to any particular next step.1
Quantify your source code exposure before the system fails
A free 30-minute consultation, followed by a fixed-fee exposure assessment if it is the right next step.
The system works until a Windows update, a server replacement, or a compliance audit forces the issue. By the point of failure, the CFO has no control over timeline, vendor selection, or scope. Financial exposure is highest when the business is forced to act under emergency conditions. CFOs who assess exposure before the system fails preserve the option to act on a planned schedule, which materially reduces total cost.
PCG performs a source code and application inventory engagement that produces a written assessment of what exists, what is recoverable, and what is at risk. The deliverable includes an exposure profile organized by business function, so the CFO can match financial risk to operational dependency. The engagement does not require migration commitment. The assessment stands on its own as a planning document.
The classification depends on the scope. A pure assessment and inventory engagement is typically an operational expense. A full source recovery followed by migration produces a new application asset that qualifies for capital treatment under standard accounting practice. PCG provides documentation suitable for either treatment and recommends consulting with the business accounting team on classification specific to the engagement.
A developer being unreachable means the knowledge in their head is gone, but the source code may still exist on company servers or backup media. Source code loss is more severe: the source files themselves cannot be located, and only the compiled application remains. Both situations are recoverable through PCG's discovery process, but source code loss extends the timeline and requires more reverse-engineering work to reconstruct the business logic.
The exposure assessment phase typically completes in 2 to 4 weeks for a mid-sized business application. The deliverable is a written report mapping each operational function to its associated financial risk if the supporting software fails. The assessment runs independently from any subsequent recovery or migration engagement. The CFO ends the assessment owning a planning document the business can use regardless of next steps.
1 Phoenix Consultants Group, My Developer Disappeared: What Do I Do? phxconsultants.com
2 Phoenix Consultants Group, Visual FoxPro Rescue When Your Developer Is Gone. phxconsultants.com
3 Phoenix Consultants Group, Conversion, Migration and Integration service page. phxconsultants.com
4 Phoenix Consultants Group, True Cost of Technical Debt: An Executive Guide. phxconsultants.com
This article is informational and reflects PCG's experience executing source code recoveries and orphaned system rescues since 1995. It is not legal, regulatory, financial, or accounting advice for any specific situation. CFOs should consult with their accounting team on expense classification and with legal counsel on contractual matters specific to their business. For guidance tailored to a particular source code exposure assessment, contact Phoenix Consultants Group directly.
When the original Visual FoxPro developer is gone and the application is still running the business, the immediate priority is preserving access to the source code, the database, and any documentation that exists. PCG performs an emergency source recovery and a written application inventory, typically within the first 2 to 4 weeks, before any migration decision needs to be made.
This situation arrives in a predictable way. Nobody currently on staff can answer a real question about how the application works. The source code lives on a network share that nobody has touched in years. Yesterday a Windows update made a report fail, and now the operations team is asking what happens next.
This article is for the business owner, CEO, or operations leader who is in that situation right now. It does not address the strategic evaluation of a planned migration. The audience here is someone who has woken up to a problem and needs to know what to do this week. If your situation has not yet reached emergency, the strategic version of the conversation is in Visual FoxPro Migration in 2026. This piece focuses on what happens when the planning window is already closed.
What does "developer is gone" actually mean for the business right now?
There are three operational realities behind the phrase, and each one has different consequences. Knowing which one applies to your situation determines what the rescue actually requires.
Developer unavailable but reachable
The original developer retired, changed careers, or moved on. They are still alive and possibly willing to answer questions, but they are not actively maintaining the application.
Developer entirely unreachable
The original developer has passed away, gone out of business, or cannot be located. Whatever knowledge they had about the application is no longer recoverable from them directly.
Developer never properly engaged
The application was built by a contractor or vendor that the business has no current contract with. Source code ownership may be unclear, and documentation may never have existed.
The rescue path is similar across all three situations because the technical work is the same: PCG reads the Visual FoxPro source code and the database schema directly. Documentation that exists in the developer's head is helpful when accessible, but it is not the primary input. The compiled application, the source code, and the production database together describe what the system actually does, and that is what gets inventoried during the rescue phase.1
What are the first three actions to take this week, before anything else?
The actions below are not about migration. They are about preserving the option to do anything at all. Each one can be completed within the first week, and each one significantly reduces the risk that the rescue becomes harder later.
First, locate every copy of the source code and back it up to a controlled location. Visual FoxPro source files are typically PRG, SCX, FRX, and VCX files in directories scattered across old development machines, network shares, and possibly a backup tape from 2014. Make a full copy to a current storage location that the business controls. If the source code lives only on the original developer's old workstation, image that machine before anything else happens to it. A workstation that boots today may not boot next month.
Second, identify and back up the production database. Visual FoxPro applications typically store data in DBF files alongside compiled executables, or in a separate data directory on a Windows file share. The DBF files are the actual business data. Take a current backup. Verify the backup is readable. If the application uses a SQL Server back-end accessed through ODBC, also take a current database backup using SQL Server tools. The data is significantly more valuable than the application that reads it, and the data is what enables any rescue scenario.
Third, document what is currently working, what is not, and who depends on each piece. A short written list of the application's main functions, the reports staff run on what schedule, the external systems it connects to, and the regulatory or compliance use cases it supports. This document does not need to be exhaustive. It needs to exist. PCG's discovery phase will produce the complete inventory, but the initial list helps prioritize which modules carry the highest business risk if the application fails.2
Visual FoxPro lost Microsoft extended support on January 13, 2015. In 2026, every VFP application is running on borrowed time. The window to act is not when the application fails. It is now, while the source code and the data are still available to recover.3
How does PCG recover the source code when nobody on staff has access?
Source code recovery is the first technical step of the rescue. PCG begins by inventorying every possible location where the source code might exist. Old development workstations, network shares, backup tapes, cloud storage accounts associated with the original developer, vendor archives, and any version control system that may have been used. PCG works with the buyer's IT team to access these locations and retrieve whatever source files can be found.
When the source code is incomplete or partially missing, PCG reconstructs what is recoverable. Visual FoxPro source files have predictable structures that PCG reads directly. PRG files contain procedural code. SCX files describe forms. FRX files describe reports. VCX files describe class libraries. Each file format is documented and readable without the original developer's interpretation. The compiled APP or EXE file also contains useful information about what the application does at runtime, even when corresponding source is unavailable for parts of the codebase.1
The output of source recovery is a controlled archive of every recoverable source file, indexed by module and function, with a written assessment of what was found and what could not be located. This archive becomes the input to the application inventory phase. The buyer ends source recovery with a definitive answer to the question of what source code the business actually possesses, which is more than many businesses had at the start of the rescue.
What happens during the application inventory phase?
The inventory phase produces a written document describing what the Visual FoxPro application actually does. What you receive is not a code-level walkthrough. It is an operational description written for the business owner, the operations team, and any future development engagement that needs to understand the system. The inventory has five components.
Functional module map
Every screen, form, and operational function the application provides, organized by business area. Staff who use the application can verify that the map matches their daily work.
Data model
Every DBF table or database object, the fields each contains, the relationships between them, and the volume of data currently stored. The data model often reveals undocumented business entities that staff did not know existed.
Business rules inventory
Validation rules, calculation logic, approval workflows, and conditional behaviors embedded in the source code. This is the component most often missing from existing documentation, and the most valuable to recover.
Reports catalog
Every report the application produces, who runs it, on what schedule, and what data sources feed it. Reports are often the most visible part of the application to non-technical staff, and their inventory has immediate operational use.
External connections
Every system the application connects to: accounting platforms, payroll, EDI partners, hardware devices, regulatory reporting systems. Each connection becomes a dependency the business must plan around.
The five components together form a deliverable the business owns regardless of what happens next. Should the decision be to migrate, the inventory becomes the foundational scope document. When the choice is to continue running the existing application for another two years, the inventory becomes the operational manual that the business never had. If the application fails before any decision is made, the inventory is the document that allows a replacement to be built without losing the embedded business knowledge.2
Speak directly with the engineer who would lead your rescue
A free 30-minute consultation to assess the urgency of your situation. No obligation, no sales handoff.
How urgent is the migration decision once the inventory is complete?
Once the inventory exists, the urgency of migration changes. The business now knows what it owns. A choice between migrating, integrating, or continuing to run the existing application becomes strategic rather than reactive. Most buyers who complete the rescue phase find that the migration question has a clearer answer than they expected, because the inventory reveals which parts of the application are truly business-specific and which parts could be served by an off-the-shelf replacement.3
The strategic version of this decision is described in detail in Visual FoxPro Migration in 2026. That article walks through the three real options of migration, integration, and replacement, and describes how each one fits a different situation. The rescue inventory is the input that allows that conversation to be productive rather than speculative.
What does not change after the inventory: the underlying technical risks of running on Visual FoxPro in 2026. Microsoft ended extended support on January 13, 2015.3 The 2 GB per-table ceiling continues to limit database growth.4 The 32-bit compatibility layer in Windows 11 continues to be a source of fragility with every feature update. The talent pool of developers who can productively work on Visual FoxPro applications continues to shrink. These conditions argue for some form of migration on a planned timeline, not on the timeline forced by the next system failure.
Before the rescue
Business is reactive
- No documented inventory of what the application does
- Source code location and completeness unknown
- Database backup status uncertain
- Business rules embedded in code that nobody can read
- Migration scope cannot be quoted without weeks of investigation
- System failure forces emergency response with no plan
After the rescue
Business has options
- Written inventory of every functional module and business rule
- Controlled archive of all recoverable source code
- Current database backup verified and stored
- Operational manual for staff and future engagements
- Migration scope quotable on real numbers from the codebase
- Decision to migrate, integrate, or continue made on the business timeline
What does emergency support cost compared to a planned migration?
Emergency support and planned migration are different engagements with different cost structures. PCG provides a fixed-fee quote for the rescue phase, including source recovery and application inventory, after a free initial consultation that assesses the situation. This quote is independent of any subsequent migration commitment. Buyers can complete the rescue phase, receive the inventory deliverable, and pause the engagement before deciding whether to proceed with migration.
The cost comparison that matters for the business owner is rescue-now versus rescue-after-failure. A planned rescue completes on a predictable schedule with the existing application still operational, staff still able to use the system, and the IT team able to support the engagement during normal business hours. When a rescue is triggered by a production failure, it runs on whatever schedule the broken business can survive. Staff who normally would contribute to discovery are instead doing manual workarounds for a system that is not working. The technical work is similar, but the operational cost of running the business during the rescue is significantly higher.2
The cost of waiting is not theoretical. It is the cost of running a rescue under emergency timeline pressure instead of a planned timeline.
PCG has been executing legacy software rescues since the late 1990s. The pattern is consistent across hundreds of engagements: businesses that initiate the rescue before a system failure spend less, lose less staff time, and arrive at the migration decision with better information. Businesses that wait until the application has broken pay a premium for compressed timelines and reduced operational flexibility. The technical work is the same. The business cost is not.
How does this differ from a planned Visual FoxPro migration?
Both engagements end with the buyer owning a clear path forward. The starting point is different. A planned migration starts with the strategic question of whether to migrate, integrate, or replace, because the business already understands what the existing application does. An emergency rescue starts earlier in the process, because the business does not yet have that understanding and cannot answer the strategic question without it.
The deliverables also differ. A planned migration produces a migrated application, the documentation package, and a reconciliation report. An emergency rescue produces a source code archive, a written application inventory, and an assessment of the next-step options. The rescue deliverable can stand on its own. Buyers who complete the rescue and decide not to proceed to migration still own a document that allows them to operate the existing system more reliably than they could before.
The two engagements connect naturally. A buyer who completes the rescue phase has, in effect, completed the discovery phase of a future migration. If the decision is to migrate, the migration engagement begins with the inventory already in hand, which compresses the overall timeline and reduces the total cost compared to a migration that includes its own discovery work from scratch.1
Find out what your Visual FoxPro application actually contains
A free 30-minute consultation, followed by a fixed-fee rescue phase if it is the right next step.
The application runs until it does not. Visual FoxPro lost Microsoft extended support on January 13, 2015, and any Windows feature update, server replacement, or compliance audit can break it without warning. The urgency is not that the system has failed. The urgency is that the business has no path to fix it when it does fail, and no documented inventory of what the application is actually doing. Building that inventory before the system breaks is significantly less expensive than building it under emergency timeline pressure.
Yes, the source code is the single most valuable asset in a rescue situation. PCG reads Visual FoxPro source directly and reconstructs what the application does without needing the original developer's interpretation. The audit phase produces a written inventory of forms, reports, business rules, stored procedures, and external integrations. The buyer ends the audit knowing what they own, which is the foundation for any decision about migration, replacement, or continued operation.
The inventory phase typically completes in 2 to 4 weeks for a mid-sized Visual FoxPro application with the source code available. Larger applications, applications with hundreds of reports, or situations where the source code must be retrieved from old backup media extend that timeline. PCG provides a fixed-fee quote for the inventory phase based on the initial assessment, separate from any subsequent migration decision.
Nothing changes in the production system during the inventory phase. PCG works against copies of the source code and the database, not the live system. Operational staff continue using the application exactly as they did before the rescue began. The first time the live system is touched is during migration cutover, and even then PCG runs in parallel rather than replacing the production system in a single weekend.
An emergency rescue starts with source code recovery and application inventory because the business does not yet know what it owns. A planned migration starts with the strategic question of whether to migrate, integrate, or replace, because the business already understands the existing application. The rescue is the first deliverable. The migration decision comes after. Buyers who go through the rescue phase often discover that they have a clearer migration scope than they would have with months of internal investigation.
1 Phoenix Consultants Group, Visual FoxPro Migration in 2026: The Real Risks and Real Path Forward. phxconsultants.com
2 Phoenix Consultants Group, My Developer Disappeared: What Do I Do? phxconsultants.com
3 Microsoft, Visual FoxPro 9.0 product lifecycle: mainstream support ended January 12, 2010; extended support ended January 13, 2015. learn.microsoft.com/en-us/lifecycle/products/microsoft-visual-foxpro-90
4 Microsoft Learn, Visual FoxPro Frequently Asked Questions: confirmation of 2 GB per-table limit and 32-bit architecture.
This article is informational and reflects PCG's experience executing emergency legacy software rescues since the late 1990s. It is not legal, regulatory, or financial advice for any specific situation. For guidance tailored to a particular Visual FoxPro application, contact Phoenix Consultants Group directly. PCG was founded in 1995.
Custom software migration cost in 2026 is driven by four compounding variables: source data complexity, target platform choice, integration scope, and historical data volume. PCG provides a fixed-price estimate after a source audit, not before. The free initial consultation determines whether the audit is the next sensible step.
Most CFOs encounter the question of migration cost the same way: a legacy system is failing, a vendor proposal arrives with a number attached, and there is no framework for assessing whether that number reflects the actual work required. The number itself is not the problem. What CFOs lack is a framework to evaluate it. This article describes the four variables that move a migration cost up or down, how a CFO should think about each one, and how PCG arrives at a fixed-price estimate after the source audit phase.
Phoenix Consultants Group has executed conversion, migration, and integration projects since 1995, with zero data loss on record across hundreds of completed engagements.1 The patterns described below come from that production history. The framework applies equally to a Microsoft Access database moving to SQL Server, a Visual FoxPro application replaced by a custom .NET Core 8 build, an Excel-based operational system consolidated into a relational database, or a legacy ERP migration to a modern platform.
What are the four variables that drive custom software migration cost?
Every custom software migration cost decomposes into four categories. A change in any one of them moves the total project number. CFOs who understand the four can interpret a vendor proposal, identify what assumptions the vendor has made, and ask the right questions before signing. The categories are not theoretical. They map directly to the work a migration team performs from the source audit through to post-cutover reconciliation.1
Source data complexity
Schema documentation, data quality, referential integrity, undocumented relationships, and the number of source systems involved.
Target platform choice
SQL Server on-premise, Azure SQL, AWS RDS, or another destination. Each carries different schema, security, and operational requirements.
Integration scope
How many systems must connect to the destination, whether APIs exist, and whether the connection is real-time or batch.
Historical data volume
Record counts, years of history retained, physical storage size, and the number of fields requiring transformation per record.
The four variables are not independent. They compound. Higher source complexity increases the time required to map fields to the target platform. Larger integration scope extends the testing window. A bigger historical data volume amplifies the impact of every transformation rule that must run against every record. Any vendor estimate that addresses only one or two of the four is incomplete by definition.
How does source data complexity change the cost equation?
Source data complexity is the single variable that most often determines whether a migration estimate proves accurate. The first signal of complexity is whether the source schema is documented. A SQL Server database with current entity-relationship diagrams, defined foreign keys, and a consistent naming convention is materially less expensive to migrate than an Access database where relationships exist only as conventions inside application code that has been modified by three developers over fifteen years.
Data quality is the second signal. Source systems that enforce required fields, constrained value lists, and referential integrity at the database level produce migration-ready data. Legacy systems that allowed users to type free text into fields that were supposed to be controlled vocabularies produce data that must be cleaned before migration. The cleaning is part of the migration work, and it is unavoidable: data that arrives at the destination without cleaning behaves incorrectly in the new system because the new system does enforce the rules the old one did not.1
The third signal is the number of source systems. A migration from one consolidated Access database is simpler than a migration that must integrate three departmental spreadsheets, an Access database, and a legacy desktop application into a single destination schema. Each source system requires its own audit, its own mapping, and its own transformation rules. The total work does not scale linearly with the number of sources because conflicts between sources must also be reconciled.
Documented and clean
Current schema documentation, defined foreign keys, enforced data types, consistent naming, single source system, controlled vocabularies for code fields.
Undocumented and inconsistent
No schema documentation, relationships embedded in application code, free-text fields where structured data was expected, multiple source systems with overlapping data, original developer unavailable.
How does the target platform choice affect total project cost?
The destination platform sets the upper bound on what the migration can achieve and the lower bound on what the migration must build. PCG currently builds on .NET Core 8 with SQL Server as the default stack, with deployment options that include on-premise SQL Server, Azure SQL Database, and AWS RDS. Each option carries different operational and cost implications that the CFO should evaluate as part of the migration planning, not after it.
SQL Server on-premise places the data inside the buyer's infrastructure. There are no recurring per-database hosting fees, and the data location decision is fully controlled by the organization. The tradeoff is that the buyer remains responsible for backup, patching, and hardware capacity planning. For organizations with existing Windows server infrastructure and IT staff already managing SQL Server, on-premise often produces the lowest total cost of ownership over a 5 to 10 year horizon.
Azure SQL Database and AWS RDS shift operational responsibility to the cloud provider. Backup, patching, and hardware capacity are handled by the platform. The tradeoff is a recurring monthly cost that scales with database size and compute capacity. For organizations without existing Windows server infrastructure, distributed teams that need multi-location access, or businesses scaling rapidly enough that hardware procurement becomes a constraint, cloud hosting often justifies the recurring cost.2
The target platform choice also determines the schema constraints the migration must satisfy. A SQL Server destination enforces referential integrity, data types, and constrained value lists that the source system may not have enforced. The migration must conform every source record to the destination schema before loading. This conformance work is part of the migration cost, and it varies with how far the source diverges from the destination requirements.
How does integration scope move the number up or down?
Integration scope is the variable most often underestimated in vendor proposals. The relevant question goes beyond whether the destination will receive data from the source. Buyers must also define which other systems must exchange data with the destination after migration is complete, on what frequency, in which direction, and under what reliability requirements.
A migration that produces an isolated destination database, with no ongoing connection to other systems, carries no integration scope. The migration completes, the new application runs, and operations continue. This is the simplest scenario. It is also the least common in 2026, when most mid-market businesses operate with multiple connected systems that exchange data continuously.
A migration that requires connection to one external system through a documented REST API carries moderate integration scope. PCG's work is to write the connector, define the data flow direction and schedule, build the error handling for connection failures, and document the integration for ongoing support. Modern systems with current API documentation produce predictable integration timelines.
A migration that requires connection to a legacy system without an API, or that requires PCG to build an API for the new system to expose data externally, carries the highest integration scope. PCG accesses the underlying database directly using ODBC or native drivers when no API exists, or builds custom extraction layers for systems that expose no programmatic interface at all. Legacy applications built before REST APIs existed are not a barrier to integration, but the work of building the integration layer is part of the migration cost.1
The four variables compound. A migration with high source complexity, a cloud destination, three integrated systems, and twenty years of historical data is not four times as expensive as a simple migration. The interactions between variables produce a multiplier effect that only a source audit can quantify.
How does historical data volume influence the cost of a migration?
Historical data volume affects migration cost through three mechanisms that compound. The first is processing time. Every record in the source system must be read from the source, run through validation and transformation rules, and then loaded into the destination. A migration of one million records runs longer than a migration of ten thousand records, and the longer the migration runs the more rigorous the parallel testing must be to confirm the production cutover will complete within the available maintenance window.
The second mechanism is data quality remediation. Larger historical datasets carry more accumulated data quality issues simply because they contain more records, more years of variation in how data was entered, and more legacy decisions about field meanings that have changed over time. A migration that retains twenty years of history carries more cleaning work than a migration that retains five.
The third mechanism is reconciliation. Post-migration reconciliation compares source record counts and key field values against destination records.1 The reconciliation effort scales with data volume because the reports must produce meaningful comparisons across the full dataset, not against a sample. Reconciliation surfaces silent failures that pre-migration validation missed, and the time required to investigate and resolve any discrepancies scales with the size of the dataset being reconciled.
A CFO who is planning a migration should ask the operational team a specific question before requesting a vendor estimate: how many years of historical data must move, and how many years could remain accessible in read-only archive without active migration? Retaining only the active operational window in the new system, while preserving the historical archive in a read-only location, often produces a meaningful reduction in migration cost without compromising business continuity.
What hidden costs do CFOs underestimate when scoping a migration?
The line items that appear in a vendor proposal are the visible costs. Hidden costs are the operational realities that the proposal does not invoice but that absorb staff time, defer revenue, or extend the project beyond the contracted window. Four hidden costs recur across migration projects.
The first hidden cost is internal staff time during discovery and validation. A migration project requires operational subject matter experts to answer questions about field meanings, business rules, and data quality decisions. The time spent in interviews, mapping reviews, and user acceptance testing is real labor that the vendor proposal does not charge for. CFOs who budget only the vendor cost miss the internal cost, which is typically 15 to 30 percent of the project effort when measured in hours.
The second is data quality remediation. Source systems that have been running for years without enforced rules accumulate quality issues. The migration surfaces every issue. Some are minor and can be corrected during transformation. Others require operational decisions: which value is correct when the same customer record exists twice with slightly different addresses, or which date is authoritative when two systems disagree. These decisions require operational judgment and absorb time.
The third is integration recertification with downstream systems. If the destination system feeds data to a reporting platform, a regulatory submission, or a partner system, those downstream consumers must validate that the post-migration data still meets their requirements. This validation is sometimes documented as a separate compliance task, and it carries its own timeline.
The fourth is post-cutover operational learning. New systems behave differently from the old one. Staff who have used the legacy system for years will need time to adapt to new workflows, even when the new system is objectively better. Training is part of the vendor cost, but the productivity dip during the first weeks of operation is not. CFOs who account for this learning curve in their financial projections see fewer surprises in the first quarter after cutover.
Speak directly with the engineer who would scope your migration
A free 30-minute consultation to evaluate which of the four variables apply to your situation. No obligation, no sales handoff.
How does PCG estimate a migration project, and when in the process does the number get fixed?
PCG does not quote a fixed price before the source audit. The reasoning is operational, not commercial. A migration estimate produced before the source audit is either inflated to cover unknown risks or committed against assumptions that may not match the actual source system. Neither outcome serves the buyer. Information gathered during the source audit is what makes a fixed-price estimate accurate.
PCG's process moves through five phases. Each phase produces a deliverable the buyer reviews before the next phase begins, and the fixed-price commitment for the full migration is made at the end of the second phase, not at the beginning of the first.1
Before the fixed price is set
Source audit phase
- Free initial consultation with the engineer who would scope the project
- Complete source schema inventory: tables, fields, relationships, constraints
- Data quality assessment with identified remediation requirements
- Source-to-destination field mapping specification
- Estimated transformation rule count and complexity
- Documented integration scope with named external systems
After the audit completes
Fixed-price commitment
- Fixed-price estimate for full migration based on actual measured scope
- Project timeline with phase-by-phase milestones
- Defined acceptance criteria for each milestone
- Documented assumptions and dependencies
- Change order process for scope additions identified later
- Reconciliation report deliverable at project completion
A vendor who quotes a fixed price without conducting a source audit is quoting against assumptions, not against the actual system. CFOs should treat that quote as preliminary, not committed.
PCG has been executing migrations on this methodology since 1995. Hundreds of Microsoft Access to SQL Server migrations, dozens of legacy ERP transitions across Sage, Great Plains, and Peachtree platforms, and operational system replacements for industrial, environmental, healthcare staffing, and airport operations clients all follow the same audit-first sequence. The fixed-price commitment is the output of the source audit, never the input to it.1
Find out which variables apply to your migration
A free 30-minute consultation, followed by the source audit if it is the right next step. The fixed-price estimate comes after the audit.
A migration estimate depends on what the source system actually contains, not on what the documentation claims it contains. The source audit measures real data volume, identifies undocumented relationships, and surfaces data quality issues that need correction before migration. A price quoted before the audit either includes a large risk premium to cover unknowns or commits PCG to a scope that may not match reality. After the audit, PCG provides a fixed-price estimate based on the actual work required.
PCG reverse-engineers the source schema directly from the database structure rather than relying on documentation. The audit maps every table, field, relationship, and constraint from the database itself. The absence of the original developer extends the audit phase but does not prevent a complete and accurate migration.
Yes. PCG's methodology runs the migration against a parallel destination environment while the source system remains the operational master. The team continues working in the existing system during migration and validation. Cutover happens only after reconciliation confirms accuracy and the buyer's team approves the results.
A fixed-price quote commits the vendor to deliver the agreed scope for a defined number. A time-and-materials quote charges by the hour with no upper bound. Fixed-price is preferable for migration projects because it forces the vendor to do the source audit work upfront. PCG provides fixed-price estimates after the source audit so the buyer knows the cost before committing to the migration.
Three safeguards prevent data loss. Pre-migration validation catches records that would fail destination schema rules before they move. A quarantine log holds failed records for review rather than silently dropping them. Post-migration reconciliation compares source record counts and key field values against destination records. No migration is considered complete until reconciliation confirms zero unresolved discrepancies.
Three deliverables: the migrated data in the destination system, the migration documentation package, and a reconciliation report confirming data integrity. The documentation includes the source audit results, the field mapping specification, the transformation rules applied, the quarantine log with resolution notes, and the post-migration reconciliation report. The package provides a complete audit trail of what moved and how it was transformed.
Yes. PCG's phased methodology produces stable checkpoints at the end of each phase. The source audit deliverable is usable on its own. The schema mapping and transformation rules document remains valid for later resumption. The parallel environment can be paused and reactivated. A pause adds re-validation time when work resumes but does not invalidate earlier phases.
1 Phoenix Consultants Group, Conversion, Migration and Integration service page. phxconsultants.com
2 Phoenix Consultants Group, Custom .NET Software Development service page. phxconsultants.com
This article is informational and reflects PCG's experience executing custom software migrations for mid-market businesses since 1995. It is not legal, regulatory, or financial advice for any specific situation. For guidance tailored to a particular migration scope, source system, or compliance context, contact Phoenix Consultants Group directly.
Custom .NET software development means building a business application from scratch on Microsoft's .NET Core 8 platform with SQL Server, designed around your operational workflow rather than forcing that workflow into an off-the-shelf product. For a mid-sized business, it is the path chosen when commercial software cannot match real operational requirements without expensive workarounds.
Most mid-market CEOs and CFOs first encounter .NET as a line on a developer's resume or a checkbox on a vendor's capability list. What they rarely receive is a plain answer to what the technology actually does for a business, when it makes sense to commission a custom application instead of purchasing an off-the-shelf product, and what the project looks like from the buyer's perspective. This article addresses those three questions in the order a buyer typically raises them.
PCG has been building .NET applications since the platform's first public release, with project records dating to 1995 when Phoenix Consultants Group was founded. The firm has delivered more than 500 production applications across industries that include environmental remediation, industrial operations, healthcare staffing, and airport ground operations.1 The observations below are drawn from that production history rather than from theoretical analysis.
What does custom .NET actually mean when you are not a developer?
.NET is a software platform built and maintained by Microsoft. It functions as the foundation on which a developer constructs your application. The current production version is .NET Core 8, released in November 2023 as a long-term support build with security and feature updates committed through November 2026.2 When a business owner hears that an application is built on .NET, the practical translation is a specific set of tradeoffs: mature tooling, a broad pool of available developers, native integration with Microsoft products, and the ability to run on Windows, Linux, or macOS servers depending on the deployment.
The word "custom" is what makes this category different from buying QuickBooks or signing up for a SaaS subscription. A custom .NET application is written specifically for your business: your workflows, your terminology, your reporting requirements, your integrations with the other systems you already run. The application is not configured from a template. Every screen and every rule is designed and built from the requirements your operational team writes down during discovery.
For a mid-sized business, the .NET stack typically includes four components working together. ASP.NET Core handles the application layer, the code that determines what happens when a user clicks a button or submits a form. SQL Server stores the operational data: customers, orders, inventory, audit logs, and the records the business runs on. Razor Pages produces the screens the user sees in the browser. JavaScript enhancements add the interactive behavior, such as live form validation and real-time filtering of data grids, that keeps the application responsive under normal use.1
Platform
Microsoft .NET Core 8, the long-term support release. Backed by Microsoft's published roadmap through November 2026.
Database
SQL Server on premise for single-site deployments, Azure SQL or AWS RDS for multi-location applications.
Interface
Razor Pages server-rendered HTML with JavaScript enhancements for the interactive parts of the screen.
When does a mid-sized business need custom .NET instead of off-the-shelf software?
Off-the-shelf software is almost always the right starting point. If a packaged product matches the work, the recommendation is to purchase it. The conversation about custom development begins when commercial software no longer accommodates the operation and the workarounds begin costing more than the original license. Four recurring situations lead mid-sized businesses to commission a custom .NET application.
The first is when the business operates on rules that no commercial product understands. An environmental remediation firm tracking soil samples against a state DEP audit schedule, a physician staffing company managing credentials across multiple facilities, an airport operator tracking ground support equipment across terminals: each of these has compliance, reporting, or operational rules specific enough that no general-purpose platform encodes them correctly. Operational staff end up working primarily inside spreadsheets that sit alongside the supposedly central system, performing the calculations the platform cannot.
A second pattern is when integration cost exceeds the cost of the software itself. Three or four operational systems run alongside each other without exchanging data. Staff re-enters the same data into each one. Reports take a week to compile because the underlying numbers reside in separate systems. Off-the-shelf middleware can sometimes bridge this gap. When it cannot, or when the middleware vendor's pricing exceeds the cost of developing a connected application, custom becomes the more economical path.
A third scenario is when the existing legacy system is failing and no commercial replacement exists. Visual Basic 6 applications, Microsoft Access databases, Visual FoxPro systems, and custom Delphi or PowerBuilder tools built in the 1990s and early 2000s continue to run mid-market production work in 2026. When the original developer is no longer available, the source code is missing, or the platform itself has reached the end of its development runway, rebuilding on .NET is often the only path forward.3
A fourth situation, increasingly common in 2026, is when a business requires AI-driven reporting against operational data and commercial products cannot connect to the database that runs the business. PCG's FireFlight Data Framework, built on .NET Core 8 with SQL Server, provides AI natural language reporting in which staff query live operational data in plain English without exporting to a separate analytics tool.1
The decision is not buy or build. The decision is whether the cost of working around a packaged product has grown larger than the cost of building software that fits the operation. By the time leadership reaches this question, the answer is typically already evident in the daily workarounds.
What does the .NET technology stack include and why does it matter for the buyer?
Most buyers do not need to understand what ASP.NET Core does at the code level. They do need to understand what choosing this stack commits them to over the next 5 to 10 years. The decisions made now about platform, database, and hosting determine which future changes will be straightforward and which will be expensive. The section below presents a non-technical view of the four components, what each contributes to the business, and what would change under a different stack.
ASP.NET Core 8
The framework that handles requests from the browser, executes business logic, and returns responses. Cross-platform and maintained by Microsoft. The practical result for the buyer is that the application can run on Windows or Linux servers without rewriting code.
SQL Server
The repository for all business data. Provides full transaction logging, rollback capability, row-level security, and complex reporting. Audit and compliance reviews proceed faster because the database itself can respond to the auditor's queries.
Razor Pages
The screens the user interacts with. Server-rendered for performance and accessibility. The application loads quickly, performs well on older devices, and remains functional when network conditions are degraded. No heavyweight JavaScript framework subject to breakage on browser updates.
On-premise or cloud
The application can be deployed on a Windows server in your facility, on Azure, on AWS, or on a private hosting provider. Data location remains a business decision driven by compliance and operational requirements, not by vendor constraint.
The combination matters because it determines what is easy to change later and what is expensive. A .NET Core 8 application with a clean separation between data access, business logic, and presentation can have its interface rewritten in five years without touching the database. The SQL Server schema, designed during the discovery phase, can absorb new fields and tables without breaking the screens that already query it. These are not abstract architectural virtues. They are the reason a custom application built in 2026 should still be running, with sensible updates, in 2036.1
What does a custom .NET project actually look like from the buyer's perspective?
The single largest source of disappointment in custom software engagements is rarely the technology itself. It is the gap between what the buyer anticipated the project would require and what the project actually demanded of the buyer's team. PCG conducts every .NET engagement through four phases. Each phase produces visible deliverables the buyer reviews before the next phase begins.
The first phase is discovery. PCG works with operational staff and technical leadership to document what the application must do, what systems it must integrate with, and what is explicitly out of scope. Discovery is conducted as a working session, not a questionnaire sent for the client to complete in isolation. The deliverables are a requirements document and a scope definition that both teams sign before any architecture work begins.1
Architecture and design review is the second phase. PCG designs the SQL Server schema, the application architecture, and the screen wireframes. A working prototype of the primary screens is built and reviewed by the buyer's team before any production code is written. This is the moment to find out that the workflow on the screen does not match how the business actually operates. Catching that mismatch on a wireframe takes an hour, while the same correction after the application has been built and deployed takes weeks of rework.
Development is the third phase and the longest part of the engagement. PCG builds the application in regular milestones, sharing working demonstrations on a recurring cadence with the buyer's team. The buyer's operational staff provides feedback during the build, not at the end. Source control, peer code review, and documented development standards are in place from day one.1
Testing, deployment, and post-launch support is the fourth phase. The application is tested against production-representative data volumes, reviewed for security, validated against the original requirements document, and deployed. Training is delivered by the engineering team. Post-launch support is provided by the same engineers who built the application.
What the buyer commits to
From discovery through launch
- Operational staff time during discovery interviews
- Review of wireframes and working prototype before development
- Feedback during milestone demonstrations
- User acceptance testing against real workflows
- Training participation from the team that will actually use the application
What PCG delivers
At project completion
- Production .NET Core 8 application on SQL Server
- Full source code with inline documentation
- Schema reference and architecture notes
- Operational runbook for ongoing administration
- Test coverage on critical business logic
- Trained operational team and a deployment that runs
A concrete example illustrates the pattern. PCG's Ground Support Equipment (GSE) management system was developed for an airport operator running fleets of tugs, belt loaders, air starters, and ground power units across multiple terminals. The previous tracking method consisted of whiteboards, spreadsheets, and manual check-in logs distributed across departments. The custom .NET Core application consolidated all of that into a centralized command center for fleet status, parts inventory, preventive maintenance scheduling, and personnel assignment. Maintenance-related downtime declined by 40 percent through predictive scheduling. Inventory visibility moved from fragmented records to 100 percent coverage across the equipment fleet.4
Speak directly with the engineer who would build it
A 30-minute consultation to assess whether custom .NET is the right fit for your situation. No obligation, no sales call.
What goes wrong when custom .NET is done badly?
Credibility on this topic comes from naming the failure modes openly, not from listing features. Four common failure patterns appear in custom .NET projects that go poorly, and each carries a recognizable signal a buyer can identify before signing the contract.
The first failure is skipping discovery. A vendor quotes a fixed price from a one-page intake form, the contract gets signed, and development begins against assumptions that were never validated with the people who will actually use the application. Six months later the system goes live and the operational team rejects it because the workflow on the screen does not match how the work is actually performed. Recovery from this point costs more than the original budget. The signal to recognize in advance: a vendor proposal with no discovery phase line item, or one that compresses discovery into a single week before development starts.
Tightly coupled architecture is the second failure mode. A developer builds the application as one large block of code where the database access, business rules, and screen rendering are intermingled. The application works when it ships. Two years later, adding a single new report requires changes across the entire codebase, and any modification carries a high risk of breaking something else. What to look for in advance: no architectural documentation in the proposal, no mention of layered design, no commitment to separating data access from business logic.
Missing documentation and source code lockout is a third common failure. The application ships, the buyer pays the invoice, and the source code is never fully handed over. Updates require returning to the original vendor at whatever rate the vendor decides to charge. The buyer has paid for software they do not actually own. To spot this in advance: contract language that retains licensing rights for the vendor, or no explicit clause stating that source code, schema documentation, and deployment configuration transfer to the buyer at delivery.
Absent test coverage on critical business logic is the fourth pattern. The application calculates payroll, compliance reports, inventory levels, or any other figure where an incorrect result carries real consequences. No automated tests verify that the calculations remain accurate as the codebase evolves. A change to one part of the application silently breaks a calculation elsewhere, and the error often goes undetected until a customer or regulator identifies it. The warning signal in a proposal: testing treated as a phase at the end of the project rather than a practice running throughout development.5
What does PCG deliver at the end of a custom .NET engagement?
The technology platform is a means. What matters at delivery is the business outcome.
A PCG custom .NET engagement closes with a defined set of deliverables. Each one exists because the absence of any one of them is what creates the failure modes described above.
- Production .NET Core 8 application on SQL Server, deployed and running in the buyer's environment, configured for the workflow the discovery phase documented.
- Full source code transferred to the buyer. No retained licensing rights, no usage restrictions, no requirement to return to PCG for modifications. Any qualified .NET developer can maintain the codebase independently.1
- Modular architecture with layered design. Data access, business logic, and presentation separated so changes to one layer do not require rebuilding the others. New features can be added as modules without touching existing functionality.1
- Secure authentication and role-based authorization with audit trails. A login system with role-based controls that enforce what each user can see and do. Sensitive operations logged with user identity, timestamp, and before/after state.1
- Schema reference, architecture notes, and operational runbook. Documentation written to support independent maintenance, not to create dependency on PCG.1
- Test coverage on critical business logic. Unit tests on the calculations the application's correctness depends on. Integration tests verifying that workflow transitions produce expected results.1
- Version-controlled source and documented deployment process. Releases are reproducible and reversible. The deployment process is documented so updates can be made without PCG's involvement.1
A custom .NET application is a capital asset. Treating it as anything less, at any phase of the engagement, is how a project that starts as a 12-month investment turns into a 5-year recurring cost.
Determine whether custom .NET is the right path for your business
A free 30-minute consultation with the engineer who would scope the project. No obligation, no sales handoff.
Low-code platforms work well for simple forms, approvals, and lightweight workflows that fit a vendor's template. Custom .NET is the right path when business logic is complex, integrations are deep, data volumes are high, or the application has to operate offline or against industrial hardware. Low-code platforms also carry per-user licensing and vendor lock-in that custom .NET avoids.
No. .NET Core 8 is cross-platform and runs on Windows, Linux, and macOS servers. Web-based .NET applications are accessed through any modern browser regardless of operating system. Desktop .NET applications still target Windows, but the majority of mid-market PCG deployments are browser-based and platform-independent for end users.
You own the source code outright at project delivery. PCG does not retain licensing rights, access controls, or usage restrictions. The delivered application includes full source, schema reference, architecture notes, and an operational runbook. Any qualified .NET developer can maintain, modify, or extend the codebase without returning to PCG.
Yes. PCG builds .NET applications with direct integrations to QuickBooks, Sage, Microsoft Dynamics, and other ERP platforms through their native APIs or database connections. Integration scope is defined during the requirements phase: which data flows between systems, in which direction, on what schedule, and with what validation rules.
Timeline depends on scope, integrations, and how well the existing process is documented before development starts. Discovery typically runs 2 to 4 weeks. A focused departmental application with a single integration moves through development faster than a multi-module operational platform with five external systems connected. PCG provides an estimate after the discovery phase, when the requirements are known, rather than committing to a number before the work has been scoped.
The engineer assigned to your project handles your technical questions directly. There is no account manager translating between your team and a remote development pool. PCG has been building .NET applications since the platform's initial release and has delivered more than 500 production applications since the firm was founded in 1995.
Modular architecture is one of the quality standards PCG applies to every .NET codebase. Applications are built in layers and modules so new functionality can be added without rebuilding existing features. A common pattern is launching with the core operational module first and adding integrations, reporting, and adjacent workflows in subsequent phases.
1 Phoenix Consultants Group, Custom .NET Software Development service page. phxconsultants.com
2 Microsoft, .NET 8 release notes and support policy. .NET 8 is a Long Term Support release with support through November 2026.
3 Phoenix Consultants Group, Visual Basic 6 Migration to .NET (Tech Wisdom). phxconsultants.com
4 Phoenix Consultants Group, Case Study: Ground Support Equipment (GSE) Management System for Airport Operations. phxconsultants.com
5 Phoenix Consultants Group, True Cost of Technical Debt: An Executive Guide. phxconsultants.com
This article is informational and reflects PCG's experience building custom .NET applications for mid-market businesses. It is not legal, regulatory, or technical advice for any specific situation. For guidance tailored to a particular operational, compliance, or procurement context, contact Phoenix Consultants Group directly. PCG was founded in 1995.
Is Corel Paradox really still in maintenance mode in 2026?
Yes, and the timeline is longer than most buyers realize. Corel Paradox was last updated in any meaningful way with the Hot Fix 1 for X4 release in 2009. Every subsequent Paradox release bundled with WordPerfect Office, including the X5, X6, X7, X8, X9, and 2020 editions, ships with the same internal build number 11.0.0.6761. The product is still sold. It just has not been developed for over fifteen years.
Why does Corel keep selling it? Because there is a long tail of customers who built business applications on Paradox in the 1990s and need access to their data. Keeping the product available is cheaper than supporting the migration. The result is that buyers paying for WordPerfect Office Professional 2020 are running the same Paradox engine that shipped in 2009.
Software does not stop working on the day development halts. The risk profile changes that day, and it keeps changing every year afterward.
What is the Borland Database Engine and why does Paradox depend on it?
The Borland Database Engine, known as BDE, is the runtime layer that every Paradox application uses to read and write .DB files. It was originally built by Borland in the early 1990s as a unified interface for desktop databases, then carried forward through Inprise and Embarcadero ownership of the Delphi and C++Builder tools that depended on it.
In 2014, Embarcadero removed the BDE installer from RAD Studio XE7 and reclassified it as a separate legacy download to make clear that the engine had been deprecated2. The official guidance was to move to FireDAC for new development. BDE was not killed outright, because too many production Paradox applications still depended on it, but it stopped receiving any meaningful updates.
Three properties of BDE matter for buyers thinking about migration:
- 32-bit only. BDE was designed for a 32-bit world and cannot be extended to 64-bit3. Modern Windows runs 32-bit applications through the WOW64 compatibility layer, which is functional but not native.
- No Unicode support. BDE predates the Unicode shift in Windows. Applications that need to handle non-ASCII characters in modern business contexts hit hard limits.
- Concurrent user ceiling. Paradox tables accessed through BDE support a maximum of 255 concurrent users per table3. A growing business eventually hits that ceiling.
What actually breaks first when you stay on Paradox?
Three failure modes show up in the field, in roughly this order. None of them announce themselves before they happen.
BDE configuration drift
Running Paradox on Windows 11 requires moving the IDAPI32.cfg file out of the Program Files directory, setting a NetFile location outside the protected paths, and running BDE Administrator as administrator4. Each Windows feature update can change permission models and break the configuration.
Shared folder lock corruption
Paradox multi-user access depends on a NetFile lock mechanism in a shared folder. When network paths change, antivirus tools quarantine the lock file, or a user reboots mid-write, the lock files corrupt and the database becomes unusable until the locks are cleared manually.
The ObjectPAL talent cliff
Developers fluent in ObjectPAL, the Paradox scripting language, are now in their sixties or retired. Finding someone who can read several thousand lines of ObjectPAL and tell you what the application actually does is a real recruiting problem, and the rate per hour reflects scarcity.
How big is the Paradox installed base in 2026?
There is no clean public count of Paradox installations the way there is for newer platforms, partly because Paradox is bundled with WordPerfect Office and many customers do not separate the two when they report what they use. What is documented is the pattern of buyers actively planning to leave it.
A useful public data point: in 2016, the Queensland Government issued a public tender for Paradox support services covering 12 production databases, with the explicit goal of maintaining them while progressing a program of work to decommission or replace each one5. Public-sector procurement is years behind private-sector pain, which means buyers in industry have been quietly running the same decision tree, just without a public tender to make it visible.
The pattern PCG sees when buyers reach out matches this. A Paradox application built in 1997 or 1998 by one developer is now running a 30-person specialty manufacturer or a 25-person environmental services firm. The application works. Nobody has touched the ObjectPAL code in over a decade. The Windows server it runs on is older than several of the employees who use it daily.
Migrate, integrate, or replace: which path fits your application?
There is no single right answer. The three real options each fit a different situation, and the wrong choice wastes time, budget, and team capacity that the business needs elsewhere.
Migrate the existing application
- ObjectPAL business rules rewritten in C# .NET with SQL Server backing
- Validation logic and referential integrity preserved where they still match the business
- Forms and reports rebuilt in modern reporting tools, not pixel-for-pixel copies
- Cutover module by module, no big-bang weekend
- Right answer when the application does something no off-the-shelf product covers
Replace with a platform
- FireFlight Data Systems modules configured to the workflow
- Data migrated from Paradox .DB files into the platform database
- Deployment measured in weeks, not months
- Right answer when the Paradox system mostly replicates what a configured platform already does
- Best fit when the workflow matches a packaged module rather than a one-off process
A third path, integration, is sometimes the realistic short-term move. Wrap the Paradox system in a modern API layer so new applications can read and write its data without depending on the BDE runtime directly. This buys time but does not retire the risk. It is a bridge, not a destination.
What does a real Paradox to SQL Server migration look like?
PCG has been running custom software projects since 1995. The migration pattern we use on Paradox work has been refined across a long list of legacy rescues. Its shape is consistent across projects. How long each phase takes depends entirely on the application being migrated.
Phase 1: Discovery
Read the .DB files. Read the ObjectPAL scripts. Read the BDE configuration. Inventory every form, report, query, secondary index, referential integrity rule, and external integration. The deliverable is a written inventory of what the application actually does, not what it was supposed to do. This is also where undocumented business rules surface, because they show up in the ObjectPAL code.
Phase 2: Architecture and quote
Decide the target stack, the SQL Server schema redesign, the integration points, the reporting tool, and the cutover sequence. PCG quotes a fixed price on the migration scope at this point. Not time and materials. Fixed scope, fixed price, with explicit assumptions documented.
Phase 3: Build in parallel
The new .NET application is built alongside the running Paradox system. Data flows are mirrored through BDE so the new system can be validated against current production results. Users are not asked to test anything until the team can stand behind the numbers.
Phase 4: Module-by-module cutover
Each functional area moves to the new application with a documented rollback path. Reports run in both systems for a defined period and outputs are compared. The Paradox application stays live until every module has cleared its checkpoint.
Phase 5: Decommission
Final data export, archive of the .DB files and the IDAPI32.cfg configuration for compliance retention, retirement of the BDE runtime. The decommission step is where compliance officers want documentation, and where the migration provides it.
What gets migrated and what gets rebuilt from scratch?
Not every piece of a Paradox application deserves to move. A careful migration is honest about which parts of the legacy system reflect business value and which parts reflect 1998 workarounds.
Business rules
Validation logic, pricing formulas, regulatory calculations, and approval workflows from ObjectPAL that still match how the business operates.
Data
Paradox .DB files convert cleanly to SQL Server via SSIS or scripted ETL through BDE. The schema gets redesigned with real constraints, not just copied.
Reports
Paradox reports rebuilt in SQL Server Reporting Services or a modern reporting tool. Visual parity is the goal where the user community depends on the layout.
UI forms
Form by form rebuild in Blazor, WPF, or a web front end. The new forms match the workflow, not the pixel layout, of the originals.
What if the original Paradox developer is gone?
Most Paradox migrations PCG quotes start exactly this way. The original ObjectPAL developer retired, moved on, or passed away years before anyone thought to capture what they knew about the system. Source files live on a network share that nobody has touched since the last meaningful change, which is usually dated somewhere between 2008 and 2015. Nobody currently on staff can answer a real question about how a particular calculation works.
This is a discovery problem, and it is solved by reading rather than interviewing. The .DB files, the ObjectPAL scripts, the BDE configuration, and the production data together describe what the application does. PCG works through this systematically during Phase 1 and produces a written inventory that the business can sign off on before any rewrite begins. The buyer ends Phase 1 knowing what they own, regardless of whether the migration moves forward.
Talk through your Paradox application with PCG
A 20-minute call. No slide deck. PCG asks about your application, your timeline, and your constraints, then tells you whether migration, replacement, or integration fits.
What drives the scope of a Paradox migration?
Every migration timeline and quote depends on the specific application. Generic answers do not exist in this work, and any quote given before a discovery phase is a guess. Five measurable inputs determine the actual scope of the project.
- Table count and schema complexity: A 15-table Paradox schema with light referential integrity is a different project from a 90-table schema with extensive secondary indexes and validity checks.
- ObjectPAL line count: Total scripting size across all forms, reports, and library files. Some Paradox applications carry thousands of lines of ObjectPAL, others almost none.
- Report count and complexity: Each Paradox report is a small project of its own. Forty reports take longer than ten.
- Integration count: Each external system the application talks to (accounting, payroll, EDI, hardware, file imports) adds discovery and rebuild time.
- BDE deployment footprint: Whether the application runs single-user on one machine or multi-user across a shared NetFile drives both the migration scope and the cutover plan.
PCG runs a fixed-fee discovery phase before quoting the migration itself. The deliverable from discovery is a written inventory of what the application does, the migration approach, and a fixed scope and timeline based on real numbers from the codebase and the BDE configuration. Buyers who go through discovery keep the deliverable whether or not they proceed to migration.
How do you avoid breaking the business during the migration?
Parallel operation is non-negotiable. The Paradox system stays in production while the new SQL Server application is built and validated. Data is synchronized between the two systems during the build phase so the new application can be tested against current production results, not stale snapshots.
Cutover happens module by module. Each module clears a defined checkpoint before the next one moves. A documented rollback path exists at every step. If something fails in the new system, the team rolls back to Paradox in minutes, not in a weekend war room. Big-bang cutover, where a business migrates everything in one weekend, fails often enough that PCG no longer offers it as an option.
31 years of running custom software projects has taught us one thing about legacy migrations: the technical risk is manageable, and the business continuity risk is what actually sinks projects.
Ready to talk specifics?
If your team is weighing a Paradox migration in the next 12 months, PCG can run a fixed-fee discovery and quote a migration path off your actual codebase.
Frequently Asked Questions
Sources
1 HandWiki. Paradox (database): documentation of the Paradox build history, including the 2009 Hot Fix 1 for X4 and the persistence of build 11.0.0.676 across subsequent releases.
2 Wikipedia. Borland Database Engine: documentation of Embarcadero's 2014 removal of the BDE installer from RAD Studio XE7 and deprecation messaging.
3 Grokipedia. Borland Database Engine: technical documentation of BDE's 32-bit architecture, lack of Unicode support, and 255 concurrent user limit per Paradox table.
4 NKnabe Database Tools. BDE and Windows 11: documented configuration workarounds required to run BDE-based Paradox applications on Windows 11.
5 Australian Tenders. Queensland Government Paradox Support Services Tender, Tender ID 259906, February 2016.
Is Visual FoxPro really unsupported in 2026?
Yes. Microsoft published the lifecycle dates years ago and they have not moved since. Visual FoxPro 9.0 mainstream support ended on January 12, 2010. Extended support ended on January 13, 20151. After that point Microsoft was no longer obligated to issue bug fixes for the language. One exception happened later: a single out-of-band security patch in March 2021 for an ActiveX control vulnerability that affected Windows itself, not VFP as a product2.
Public CVE records list more than a dozen documented vulnerabilities affecting VFP ActiveX controls, including memory corruption issues in MSCOMCTL.OCX and FPOLE.OCX that allow remote code execution3. None of those will be patched in the VFP runtime. They sit there, indefinitely, in every compiled VFP application that uses the affected components.
Software does not stop working on the day support ends. The risk profile changes on that day, and it keeps changing every year afterward.
What actually breaks first when you stay on VFP?
Three failure modes show up in the field, in roughly this order. None of them announce themselves before they happen.
Windows feature updates
Each Windows 11 feature release adjusts the WOW64 32-bit layer, printing subsystem, and font rendering. VFP reports built before 2010 are the most fragile. The application opens fine the morning after the update, then a report fails at month-end.
The 2 GB table ceiling
VFP tables are capped at 2 GB each due to 32-bit addressing4. Inventory, transaction, and audit log tables that grew slowly for years hit the ceiling at the worst possible moment, usually during a busy quarter, and writes start failing without a clean error message.
The talent cliff
FoxPro DevCon ran for the last time in 2009. Developers who built production VFP systems in the late 1990s are retiring. Finding someone who can read 200,000 lines of legacy FoxPro and tell you what it does is a real recruiting problem, and the rate per hour reflects scarcity.
How big is the VFP installed base in 2026?
The market data confirms what PCG sees in the field. According to Enlyft, more than 5,400 companies worldwide still ran Visual FoxPro in 2025, concentrated in IT services, software, and small to mid-sized businesses of 10 to 50 employees5.
Those numbers track with the pattern we see when buyers reach out. A VFP application built in 1998 by a single developer is now running a 30-person manufacturer or a 20-person environmental services firm, and the buyer is one of three people in the building who remembers how it was deployed. The application works. Nobody has touched it in years. The Windows server it runs on is older than several employees.
That last detail is the one that matches every VFP project we have run since the late 1990s. The code is migratable. What gets in the way is that nobody in the building can describe what the code is supposed to do, because the person who wrote it retired in 2017 and the documentation lives on a Word file someone last opened in 2014.
Migrate, integrate, or replace: which path fits your application?
There is no single right answer. The three real options each fit a different situation, and the wrong choice wastes time, budget, and team capacity that the business needs elsewhere.
Migrate the existing application
- VFP code rewritten in C# .NET with SQL Server backing
- Business rules preserved line by line where they still match the business
- Reports and forms rebuilt in modern reporting tools
- Cutover module by module, no big-bang weekend
- Right answer when the app does something no off-the-shelf product covers
Replace with a platform
- FireFlight Data Systems modules configured to the workflow
- Data migrated from VFP DBF files into the platform database
- Deployment measured in weeks, not months
- Right answer when the VFP system mostly replicates what a configured platform already does
- Best fit when the workflow matches a packaged module rather than a one-off process
A third path, integration, is sometimes the realistic short-term move. Wrap the VFP system in a modern API layer so new applications can read and write its data without depending on the VFP runtime. This buys time but does not retire the risk. It is a bridge, not a destination.
What does a real Visual FoxPro to .NET migration look like?
PCG has been running custom software projects since 1995. The migration pattern we use on VFP work has been refined across a long list of legacy rescues. Its shape is consistent. Duration depends on size.
Phase 1: Discovery
Read the source code. Read the production database. Inventory every form, report, stored procedure, scheduled task, and external integration. The deliverable is a written inventory of what the application actually does, not what it was supposed to do. This is also where invented or undocumented business rules surface, because they show up in the code.
Phase 2: Architecture and quote
Decide the target stack, the schema redesign, the integration points, the reporting tool, and the cutover sequence. PCG quotes a fixed price on the migration scope at this point. Not time and materials. Fixed scope, fixed price, with explicit assumptions documented.
Phase 3: Build in parallel
The new .NET application is built alongside the running VFP system. Data flows are mirrored so the new system can be validated against current production results. Users are not asked to test anything until the team can stand behind the numbers.
Phase 4: Module-by-module cutover
Each functional area moves to the new application with a documented rollback path. Reports run in both systems for a defined period and outputs are compared. The VFP application stays live until every module has cleared its checkpoint.
Phase 5: Decommission
Final data export, archive of the legacy system for compliance retention, retirement of the VFP runtime. The decommission step is where compliance officers want documentation, and where the migration provides it.
What gets migrated and what gets rebuilt from scratch?
Not every line of VFP code deserves to move. A careful migration is honest about which parts of the legacy system reflect business value and which parts reflect 1998 workarounds.
Business rules
Validation logic, pricing formulas, regulatory calculations, and approval workflows that still match how the business operates.
Data
DBF files convert cleanly to SQL Server via SSIS or scripted ETL. The schema gets redesigned, not just copied, so the result is faster and easier to maintain.
Reports
VFP reports rebuilt in SQL Server Reporting Services or a modern reporting tool. Visual parity is the goal where the user community depends on the layout.
UI forms
Form by form rebuild in Blazor, WPF, or a web front end. The new forms match the workflow, not the pixel layout, of the originals.
What if the original Visual FoxPro developer is gone?
Most VFP migrations PCG quotes start exactly this way. The original developer retired, moved on, or passed away years before anyone thought to capture what they knew about the system. Source code lives on a network share that nobody has touched since the last meaningful change, which is usually dated somewhere between 2012 and 2018. Nobody currently on staff can answer a real question about how a particular calculation works.
This is a discovery problem, and it is solved by reading rather than interviewing. The source code, the compiled executable, the database schema, and the production data together describe what the application does. PCG works through this systematically during Phase 1 and produces a written inventory that the business can sign off on before any rewrite begins. The buyer ends Phase 1 knowing what they own, regardless of whether the migration moves forward.
Talk through your VFP application with PCG
A 20-minute call. No slide deck. PCG asks about your application, your timeline, and your constraints, then tells you whether migration, replacement, or integration fits.
What drives the scope of a Visual FoxPro migration?
Every migration price and timeline depends on the specific application. Generic answers do not exist in this work, and any quote given before a discovery phase is a guess. Five measurable inputs determine the actual scope of the project.
- Lines of code: Total VFP source size, including stored procedures and triggers. A 50,000-line application is a different project from a 500,000-line one.
- Database size and table count: A 50-table schema with 4 GB of data quotes differently from a 12-table schema with 80 GB of data.
- Report count and complexity: Each VFP report is a small project of its own. Forty reports take longer than ten.
- Integration count: Each external system the application talks to (accounting, payroll, EDI, hardware) adds discovery and rebuild time.
- ActiveX control inventory: Third-party ActiveX controls used in the application drive scope, because each one needs a modern equivalent.
PCG runs a fixed-fee discovery phase before quoting the migration itself. The deliverable from discovery is a written inventory of what the application does, the migration approach, and a fixed scope and timeline based on real numbers from the codebase. Buyers who go through discovery keep the deliverable whether or not they proceed to migration.
How do you avoid breaking the business during the migration?
Parallel operation is non-negotiable. The VFP system stays in production while the new .NET application is built and validated. Data is synchronized between the two systems during the build phase so the new application can be tested against current production results, not stale snapshots.
Cutover happens module by module. Each module clears a defined checkpoint before the next one moves. A documented rollback path exists at every step. If something fails in the new system, the team rolls back to VFP in minutes, not in a weekend war room. The big-bang cutover, where a business migrates everything in one weekend, fails often enough that PCG no longer offers it as an option.
31 years of running custom software projects has taught us one thing about legacy migrations: the technical risk is manageable, and the business continuity risk is what actually sinks projects.
Ready to talk specifics?
If your team is weighing a VFP migration in the next 12 months, PCG can run a fixed-fee discovery and quote a migration path off your actual codebase.
Frequently Asked Questions
Sources
1 Microsoft. Microsoft Visual FoxPro 9.0 Lifecycle. learn.microsoft.com/en-us/lifecycle/products/microsoft-visual-foxpro-90
2 Microsoft Download Center Archive. Visual FoxPro 9.0 Service Pack 2 Security Update, March 2021.
3 CVE Details. Microsoft Visual FoxPro: Security Vulnerabilities, CVEs. cvedetails.com
4 Microsoft Learn. Visual FoxPro Frequently Asked Questions: confirmation of 2 GB per-table limit and 32-bit architecture. learn.microsoft.com/en-us/previous-versions/visualstudio/foxpro/mt490124
5 Enlyft. Companies using Microsoft Visual FoxPro, 2025 market data, cited via NetLib Security.
PCG Resource Library
In-depth guides for operations leaders running businesses on systems older than the people who maintain them. Written by Allison Woolbert, principal of Phoenix Consultants Group since 1995.
Executive Guides
9 articlesDecision-level guides for CEOs, CFOs, and operations leaders on the architectural problems that drive cost and risk in growing businesses. Each guide explains a specific symptom, traces the root cause, and outlines the structural fix.
- 10-Day Reporting Lag: What It Costs, Why It Happens, and How to Eliminate It
- ERP Scalability Problem: When the System That Got You Here Cannot Get You There
- Hidden Cost of Data Silos: An Executive Guide to Unified Operations
- Silent Margin Killer: An Executive Guide to Identifying and Closing Invisible Profit Leaks
- Spreadsheet Trap: Ending the Manual Workaround Tax
- The Inventory Accuracy Problem: What It Is Costing Your Production Floor
- The IT Key-Man Risk: An Executive Guide to Building Systems That Outlast Any Individual
- True Cost of Technical Debt: When Patching Is More Expensive Than Replacing
- When Growth Breaks the Business: The Architectural Fix That Frees the CEO to Lead
Custom Software Development
5 articlesWhen custom development is the right answer, what it costs, how long it takes, and how to scope the project before signing a contract. For founders and operations leaders evaluating build vs buy decisions.
Legacy Software Rescue & Migration
10 articlesPractical paths off Visual FoxPro, Visual Basic 6, Microsoft Access, and other discontinued platforms. Includes emergency rescue when the original developer is gone, when the source code is lost, or when the system is breaking under load.
- The Microsoft Access Exit Strategy: An Executive Guide to Migrating Legacy Databases
- Access to SQL Server: What Happens to Forms, Reports, and Macros?
- Visual Basic 6 Migration to .NET
- VB6 Migration Target: Desktop or Web Application?
- Visual FoxPro Migration in 2026: Why It Is a Liability and How to Move
- Visual FoxPro Rescue When Your Original Developer Is Gone
- Paradox Database Migration in 2026
- The Cost of Losing Your Business Software Source Code
- My Developer Disappeared: What Do I Do?
- Emergency Software Support
ERP Migration
2 articlesReplacing a business-critical ERP without stopping operations. When to move off Sage, Great Plains, or Peachtree, and how parallel-run migration keeps both environments live until the new system is validated.
AI Integration & Business AI Resilience
2 articlesConnecting business systems directly to AI, and building a continuity plan for when cloud AI providers fail. The Business AI Backup Plan series continues by email after Part 1.
Environmental & Field Data
3 articlesCustom software for environmental consultants, EHS directors, and regulatory compliance teams running field operations. When Excel and paper-based workflows stop meeting audit expectations.
Data Architecture & Integration
1 articleConnecting systems that were not designed to talk: middleware, data movement, and integration architecture for businesses running parallel systems that need to share data without manual exports.
Have a legacy system or custom software question?
PCG has been running legacy migrations and custom development engagements since 1995. Book a 20-minute call to talk about what the right next step looks like for your situation.
- 1
- 2