Custom .NET beats off-the-shelf SaaS in four specific situations: when business logic is too specific for any vendor template, when integration cost exceeds the license cost, when SaaS pricing scales worse than custom ownership at the business's volume, and when data sovereignty or compliance requirements rule out shared cloud platforms.
Most CEOs encounter the SaaS-versus-custom question the same way: a department head is frustrated with the current SaaS product, a vendor proposal arrives for a custom build, and there is no framework for assessing whether the proposal addresses a real problem or whether a different SaaS subscription would solve the situation more cheaply. This choice is not theoretical. The wrong answer in either direction costs measurable money, and the right answer depends entirely on the specific business situation rather than on general claims from either category of vendor.
Phoenix Consultants Group builds custom .NET applications and has done so since 1995, across more than 500 production engagements. PCG also routinely recommends SaaS when SaaS is the right answer. The honest version of this article is the one a CEO needs: a framework for distinguishing the situations where each approach wins, written by a company that has no interest in selling custom development when SaaS would solve the problem.1
When does SaaS actually win the decision?
SaaS is almost always the right starting point. If a packaged product matches the work the business does, the recommendation is to purchase it.2 The conversation about custom development begins when commercial software no longer accommodates the operation, not before. CEOs evaluating the question should start by identifying whether their situation matches the standard SaaS pattern. Most situations do, which is why most businesses run on commercial software rather than custom applications.
Standard workflow is the first signal that SaaS is the right choice. When the business runs a workflow that hundreds or thousands of other businesses run in essentially the same way, a SaaS vendor has already built the application. Accounting, CRM, project management, helpdesk, payroll for businesses without compliance specifics, expense reporting, and similar functions have mature SaaS markets with multiple competing products. The CEO's job is to select the best product for the specific business, not to commission a custom build.
Small IT footprint is the second signal. SaaS shifts operational responsibility to the vendor: backup, patching, security updates, and hardware capacity are the vendor's problem. For businesses with small IT teams that cannot productively manage on-premise infrastructure, SaaS removes a category of work the business does not want to own. The recurring license fee is the cost of avoiding that operational burden. That trade is rational for many businesses and remains so for as long as the SaaS product fits the work.
Low user volume is the third signal where SaaS pricing remains favorable. Most SaaS products are priced per user per month. At small user counts, the monthly fee is materially lower than the upfront development cost of a custom application that would do the same work. The math changes at higher user volumes, which is where the custom case begins to surface, but it remains favorable to SaaS at the small end of the volume spectrum.
Fast implementation requirement is the fourth signal. SaaS products typically deploy in days to weeks. Custom development runs in weeks to months depending on scope. When the business needs an operational capability now, and the SaaS market has a product that approximates the requirement, the speed advantage of SaaS frequently outweighs the long-term cost difference. The custom rebuild can happen later if needed.
What are the four situations where custom .NET beats SaaS?
The custom case is not the inverse of the SaaS case. It does not surface when "SaaS is bad." It surfaces in four specific situations where the structural assumptions that make SaaS economical break down for a particular business. CEOs who recognize one or more of these situations in their operation have a real reason to consider custom development. Businesses that do not match any of them should remain with SaaS.2
Business logic too specific for any vendor template
The business operates on rules, calculations, or workflows specific enough that no SaaS template encodes them correctly. Staff end up working primarily in spreadsheets that sit alongside the SaaS product, doing the calculations the platform cannot.
Integration cost exceeds license cost
The business runs three to five SaaS subscriptions that were each purchased to fill a gap in another. The integration burden between them, measured in staff time and middleware fees, exceeds the recurring license cost of the SaaS portfolio itself.
SaaS pricing scales worse than custom at volume
Per-user, per-record, or per-transaction fees compound until the recurring cost of SaaS surpasses the amortized cost of a custom application that does the same work. The crossover point depends on the specific volume and vendor pricing.
Data sovereignty or compliance rules out shared cloud
Regulatory frameworks or contractual obligations require that the business data reside on infrastructure the business controls. SaaS architectures, which depend on shared cloud platforms operated by the vendor, are excluded by the underlying compliance requirement.
Each of the four situations is independently sufficient to make custom development the right answer. They do not need to compound. A business that hits any one of them has a legitimate custom case. Operations that hit two or more have a case so strong that the CEO who continues running SaaS workarounds is actively losing money the business could redirect.1
How does SaaS pricing scale compared to custom .NET ownership?
The pricing structures of the two approaches are fundamentally different, and CEOs who do not understand the difference make the comparison incorrectly. SaaS is a recurring operating expense that scales with usage. Custom .NET is a capital investment that amortizes across the application's productive life. The two are not directly comparable on a monthly basis, but they are comparable across a multi-year horizon if the analysis is done correctly.
SaaS pricing typically follows one of three models. Per-user fees charge a fixed amount per active user per month, which scales linearly with headcount. Volume-based pricing charges based on the records stored or processed, which scales with the business's operational activity. Transaction-based pricing charges based on specific actions taken in the platform, which scales with the throughput of whatever process the SaaS supports. Most SaaS products use one of these models or a combination, and the model determines how the recurring cost grows over time.
Custom .NET ownership has a different cost profile. The upfront development cost is significant. After deployment, the recurring cost is hosting infrastructure, periodic maintenance, and any feature additions the business commissions. For a business operating at low user volumes, the SaaS recurring cost is materially lower than the amortized cost of custom development across the same period. Higher user volumes or growing transaction throughput change the calculation: the SaaS recurring cost continues to grow while the custom asset remains fully owned at no incremental license fee.3
The CEO question is not which approach is cheaper today. It is which approach is cheaper across the application's productive life, given the specific business volume, integration scope, and compliance requirements. The honest answer depends on the audit, not on the brochure.
What hidden costs do CEOs underestimate when evaluating SaaS?
The SaaS license fee is the visible cost. Several hidden costs accumulate alongside it, and CEOs who budget only the license miss the real comparison against custom development. Four hidden costs recur across mid-market SaaS evaluations.
Integration cost is the first hidden component. When the business runs multiple SaaS platforms, each one needs to exchange data with the others to avoid manual re-entry. Some platforms provide native integrations, but the most useful integrations frequently require middleware platforms like Zapier, MuleSoft, or custom-built connectors. The middleware carries its own monthly fee, and the connectors require ongoing maintenance as either platform updates its API.
Customization workaround cost is the second hidden component. When the SaaS product does not match the business workflow exactly, staff develop workarounds: spreadsheets that hold data the SaaS does not capture, side processes that compensate for missing functionality, and manual approval workflows that bypass the platform's standard logic. The labor cost of these workarounds is invisible in the SaaS budget line but appears in productivity loss that CEOs notice without attributing to the cause.
Data lock-in cost is the third hidden component. SaaS vendors structure their terms of service to retain ownership and control of the data stored in their platforms. When the business decides to migrate away from a SaaS product, the export process is often incomplete, the data formats are proprietary, and the historical context that gave the data meaning is lost. The cost of recovering the business's own data from a SaaS platform exit can equal years of license fees.4
Vendor pricing risk is the fourth hidden component. SaaS vendors raise prices regularly, and the business has limited recourse once it has built operational dependence on the platform. A SaaS subscription that was economical at the original price may not remain economical after three or four annual price increases. The cost of switching to a different SaaS product, or to custom development, must be weighed against the cumulative cost of remaining on the original platform under its updated pricing.
Speak directly with the engineer who would scope your buy-or-build assessment
A free 30-minute consultation to evaluate whether SaaS or custom .NET is the right path for your business. No obligation, no sales handoff.
How does data sovereignty factor into the decision?
Data sovereignty is the fourth situation where custom .NET beats SaaS, and the only one where SaaS is excluded by the underlying requirement rather than out-economized over time. Businesses operating under specific regulatory frameworks, contractual obligations to large customers, or legal exposure that requires controlled data location cannot use SaaS for the affected business functions regardless of how favorable the pricing or integration is.
Three categories of business face this constraint regularly. The first is businesses operating under federal compliance frameworks that require data to reside on infrastructure controlled by the business, including specific government contracting requirements, defense-related obligations, and federally-regulated industries with strict data handling rules. A second category is businesses serving large enterprise customers whose security review processes prohibit vendor relationships that involve customer data passing through shared cloud platforms. Jurisdictions with data residency laws form the third category: those laws require specific physical storage locations for particular categories of data, which excludes shared cloud SaaS by definition.3
Custom .NET deployment supports all three scenarios because the deployment location is a buyer decision. The application can run on a Windows server in the buyer's facility, in a private hosting environment dedicated to the buyer, or on cloud infrastructure configured to meet the specific sovereignty requirements. SaaS architectures, which depend on shared cloud platforms operated by the vendor, do not provide that flexibility. The CEO who has data sovereignty as a constraint does not have a choice between SaaS and custom. That choice has already been made by the regulatory or contractual requirement.
What does the buy-or-build assessment actually look like at PCG?
PCG performs a buy-or-build assessment as a defined engagement designed to produce a CEO-grade decision document. The assessment is platform-neutral. When SaaS is the right answer, PCG recommends SaaS and identifies the specific products to evaluate. When custom is the right answer, PCG quotes the fixed-price engagement after the source audit. The assessment is the deliverable, not a sales pitch for custom development.
What the assessment evaluates
Buy-or-build inputs
- Current SaaS portfolio inventory and license costs
- Integration burden between SaaS platforms
- Business logic specificity against vendor templates
- User volume and projected growth trajectory
- Data sovereignty and compliance requirements
- Staff time spent on workarounds and manual processes
What the assessment delivers
Written CEO decision document
- Platform-neutral recommendation with reasoning
- SaaS product short-list if SaaS is the right answer
- Custom .NET scope and approach if custom is the right answer
- Identified hybrid options where mixed approach fits
- Multi-year cost comparison framework
- Migration pathway if existing SaaS is being replaced
The assessment phase typically completes in 2 to 4 weeks. The CEO ends the engagement owning a decision document the business uses regardless of which path is chosen.
PCG's approach to the assessment reflects 31 years of running custom software projects and recommending against custom development whenever SaaS would solve the problem. The platform-neutral framing is not marketing positioning. It is operationally how PCG has filtered engagements since 1995, because committing to a custom build that should have been a SaaS purchase produces a project that disappoints the buyer and damages the consultancy's reputation. Both outcomes are worse than recommending SaaS when SaaS is the right answer.1
Can a business start with SaaS and migrate to custom later?
Yes, and most businesses that end up on custom .NET arrived there through this path. The sequence is common enough that PCG treats it as the default expectation: businesses start with SaaS when their operational requirements are still emerging, encounter the specific situations where SaaS no longer fits, and migrate to custom when the case becomes clear. Migration is a defined engagement, and the SaaS data moves with the business rather than being abandoned.4
The transition typically happens in one of three patterns. The first pattern is replacement: a single custom .NET application replaces a single SaaS subscription that no longer fits. Consolidation is the second pattern: a single custom .NET application replaces three to five SaaS subscriptions that were purchased to cover gaps in each other, with the consolidation eliminating both license fees and integration burden. Hybrid is the third pattern: custom .NET handles the business-specific operations while SaaS continues to handle standard functions like email, accounting, or HR.
Each pattern carries different scope, timeline, and complexity. PCG's source audit determines which pattern fits the business and quotes the migration accordingly. The audit also identifies whether the migration should happen now, in phases, or be deferred until specific operational triggers occur. CEOs end the audit with a documented transition plan rather than a binary commit-now-or-not decision. That documented plan is itself a planning asset the business uses regardless of which path is ultimately chosen.
Find out whether SaaS or custom .NET fits your situation
A free 30-minute consultation, followed by a fixed-fee buy-or-build assessment if it is the right next step.
SaaS is almost always less expensive in the first 12 to 18 months because it carries no upfront development cost. The comparison changes after the third year as license fees compound while a custom asset is fully paid off. The crossover point depends on the specific business volume, the integration scope, and how often the SaaS vendor raises prices. PCG's source audit determines where the crossover falls for each business rather than relying on generic claims from either side of the debate.
Yes. Custom .NET applications frequently replace three to five SaaS subscriptions that were originally purchased to cover gaps in each other. PCG's source audit identifies the actual business functions performed across the existing SaaS portfolio and designs a single custom application that performs those functions in one working environment. The consolidation eliminates per-subscription license fees and removes the integration burden between previously disconnected SaaS platforms.
PCG migrates SaaS data into the custom .NET application as part of the build engagement. Each SaaS platform's data export is mapped to the destination schema, cleaned for quality issues identified during the audit, and loaded with reconciliation confirming that what left the source arrived at the destination. The buyer ends the migration owning the historical data outright, which is rarely the case under SaaS terms of service.
The decision typically takes 2 to 4 weeks once the source audit is underway. PCG's audit produces a written assessment of which SaaS platforms the business currently runs, what gaps drove their selection, what integration costs are accumulating between them, and where the custom .NET path produces a measurable improvement. The audit stands on its own as a planning document regardless of the final decision.
Yes. PCG performs a buy-or-build assessment that maps the business requirements against both SaaS and custom .NET options. The assessment is platform-neutral. When SaaS is the right answer, PCG recommends SaaS and identifies the specific products to evaluate. When custom is the right answer, PCG quotes the fixed-price engagement after the source audit. The assessment is the deliverable, not a sales pitch for custom development.
1 Phoenix Consultants Group, Custom .NET Software Development for Mid-Sized Business. phxconsultants.com
2 Phoenix Consultants Group, Custom .NET Software Development service page. phxconsultants.com
3 Phoenix Consultants Group, What Drives Custom Software Migration Cost. phxconsultants.com
4 Phoenix Consultants Group, The Cost of Losing Your Business Software Source Code. phxconsultants.com
This article is informational and reflects PCG's experience building custom .NET applications and advising on SaaS-versus-custom decisions since 1995. It is not legal, regulatory, financial, or procurement advice for any specific situation. For guidance tailored to a particular buy-or-build evaluation, contact Phoenix Consultants Group directly. PCG was founded in 1995.
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.
Custom .NET Software &
Full-Stack Data Solutions
Phoenix Consultants Group designs, builds, and rescues custom software for industrial, environmental, and operational organizations. Since 1995, the firm has delivered more than 500 applications across fleet management, compliance tracking, healthcare staffing, public safety, and legacy system migration. When a business-critical system fails and the original developer is no longer available, PCG provides the technical resolution.
- 500+ Applications Delivered
- 3 Decades in Operation
- ExxonMobil | Nabisco | AXA Financial
1995
Year of Founding
F500
Project Experience
30+
Year in Business
45+
Industries Served
Building Custom,
Data-Driven Applications That Power Business
We are a custom software development firm specializing in legacy system migration, compliance software, and full-stack .NET development for industrial and operational organizations. Founded in 1995, we have delivered more than 500 production applications. Our engineers work directly on every engagement, and all technical inquiries are handled by the engineer assigned to the project.
Last updated: April 2026
Core Development and Migration Services
Custom .NET Software Development
PCG develops production software on C# .NET Core 8, ASP.NET Core, Razor Pages, and SQL Server for organizations whose operational requirements exceed the capabilities of available commercial products. Completed systems have included fleet management platforms, physician credentialing and payroll systems, compliance tracking applications, and public safety dispatch software. Full source code ownership transfers to the client at project completion.
Environmental and Industrial Compliance Software
Compliance software has represented approximately one-third of PCG's three-decade project volume: waste manifests, air permits, EPA Title V, remediation documentation, and OSHA record keeping. FireFlight Data System is a modular platform developed and maintained exclusively by PCG for environmental compliance and industrial operations, delivering that same depth of domain experience in a fully hosted, directly supported system.
Legacy System Migration and Application Rescue
PCG migrates Access databases, VB6 applications, FoxPro systems, legacy ASP applications, and Excel-based operational systems to current .NET Core 8 architecture. Business logic, data integrity, and process workflows are preserved through the migration. Existing documentation is not a prerequisite for initiating an engagement. PCG performs technical reconstruction where source documentation is absent.
Experienced Database Administrators and Software Engineers Since 1983
At Phoenix Consultants Group, our database administrators have been developing and delivering data collection and data management applications since 1983. We have the depth of experience required to write software that meets and exceeds client requirements, with extensive work in database synchronization, multi-source data collection, and the architecture of compact, high-performance database systems.
We maintain active expertise in both current and legacy programming environments, enabling us to migrate, maintain, and modernize systems regardless of the platform on which they were originally built
Programming Expertise in Both Modern and Legacy Languages
We have maintained current expertise across both modern development frameworks and legacy languages. This dual capability is the technical foundation for our migration work: our engineers understand both the platform a system was built on and the platform it is being migrated toward.
- Visual Basic, Visual Basic for Applications, SQL Server, Microsoft Access & Excel, ASP, C#.Net, Visual Basic.NET, Razor.NET, Core.NET, ASP.NET, Java, PHP
- MS SQL Server, OLEDB, ADO, ODBC, MS Access, MySQL
- OLE/ActiveX, COM/DCOM/COM+
- DOS, dBase, FoxPro, Paradox, Alpha, RM Cobol
Let's Start Your Project!
Project Portfolio
At Phoenix Consultants Group, we have worked in a vast number of industries. Below are some of our latest custom software and programming projects.
Satisfied Customers
Years Experience
Software Languages
Industries
Technical Situations That Typically Precede an Engagement With Us
A production system has no surviving documentation and the original developer is no longer available.
We have performed technical reconstruction and migration on production systems accumulated over 10 to 20 years of development, in cases where no documentation, design specifications, or original developer access existed. The completeness of documentation at project initiation does not determine whether a successful migration is achievable.
A Microsoft Access database is generating errors that internal staff cannot resolve.
We have maintained and migrated Microsoft Access systems across all versions of the platform since its initial release. Data corruption, version incompatibility, 32-bit architectural constraints under Windows 10 and 11, and performance degradation under scaled data volume are recurring issues with established resolution paths at PCG.
Compliance requirements are specific enough that no available commercial EHS platform provides an adequate fit.
Environmental consulting firms, industrial EHS departments, and field inspection organizations operating under agency-specific regulatory frameworks frequently encounter this gap. We have built compliance software across all three contexts: FireFlight Data System provides natural language query capability against live operational and compliance data.
A critical operational process is managed within a spreadsheet that represents an institutional single point of failure.
When the individual with working knowledge of a complex operational spreadsheet departs, the organization loses both the tool’s functionality and the institutional knowledge embedded in its logic. We convert these systems to documented, maintainable applications before that dependency becomes an operational crisis.
Some Industries
That We Serve
Emergency Services
Engineering
Environmental Safety
Fortune 500
Industrial Safety
Industry
Information Technologies
Inventory Management
Manufacturing Software
Non Profit Services
Oil & Gas
Regulation Compliance
Retail
Small Business
Transportation
FireFlight Data System:
A Modular Platform Developed and Maintained Exclusively by PCG
FireFlight Data System is our proprietary modular software platform for environmental compliance, industrial operations, and field data management. Built on .NET Core 8 and SQL Server, the system is hosted and maintained entirely by us. Our clients receive a fully operational system with ongoing engineering support. Infrastructure management, security maintenance, and platform updates remain our responsibility for the duration of the engagement.
- Waste manifest tracking and regulatory deadline management
- Multi-site air permit monitoring and exceedance alerting
- Remediation milestone documentation and audit trail management
- EPA and state DEP compliance record management
- Field inspection data capture and regulatory report generation
- PCG-hosted infrastructure with direct engineering support
Technical and Commercial Questions Addressed Before Engagement
PCG migrates Visual Basic 6 applications to modern .NET. We have been doing this work since VB6 was current software, which means we understand what these systems actually do before touching a line of code. Most migrations take 8 to 20 weeks depending on application size and documentation available. Your business logic comes through intact. So does your data.
Why are VB6 applications failing in 2026?
Visual Basic 6 reached end of support from Microsoft in 2008. The runtime persisted through Windows compatibility layers, but that window is closing fast. In 2026, the failure points are stacking up: 64-bit Windows dropping 32-bit COM component support, third-party controls with no working installers, and hardware refreshes that simply will not run the old runtime environment at all.
The businesses still running VB6 applications are not doing so because they prefer VB6. They are running them because the application works and the migration felt expensive. Nobody wanted to touch something that was not broken. In 2026, more of those applications are breaking. A Windows update that rolled out silently at 2am is a common trigger. So is a new machine purchase where IT discovers the application will not install.
- 64-bit Windows environments removing legacy 32-bit COM support
- ActiveX controls with no current vendor support or installer
- Crystal Reports components tied to VB6 versions with no upgrade path
- DAO and RDO data access layers deprecated in current SQL Server
- Hardware refreshes where the VB6 runtime simply will not install
- Windows 11 compatibility breaks that appear without warning after updates
- SSL/TLS library dependencies that no longer function in modern network environments
The cost of waiting is no longer theoretical. Every month a VB6 application stays in production on modern hardware is a month closer to a failure that forces the migration under crisis conditions rather than planned ones. PCG has handled both scenarios. The planned migration costs significantly less.1
What does PCG actually do during a VB6 to .NET migration?
The migration is not a code conversion. Automated tools exist that will translate VB6 syntax to VB.NET syntax line by line, and the result is almost always unmaintainable code that carries every architectural problem of the original into the new platform. PCG does not use that approach.
The work starts with understanding what the application does. VB6 systems running for 15 or 20 years often contain business logic that exists nowhere else in the organization. Rules encoded in 2004 by a developer who is no longer there, handling edge cases that nobody currently remembers exist. PCG documents that logic before writing a single line of new code.
PCG reads the existing VB6 codebase and produces a plain-English document of what the application does and what business rules are embedded in the code. This becomes the specification for the new system.
Based on what the application does and how it is used, PCG recommends the target platform. Most VB6 applications migrate to C# .NET Core with a web front end. Desktop applications with specific hardware dependencies may stay as Windows desktop apps, rebuilt in modern WPF or WinForms. The decision is driven by the business need, not by what is easiest to build.
VB6 applications typically connect to Access databases or older SQL Server versions. PCG migrates the data to a current SQL Server schema, cleaning and normalizing records in the process. The new application connects to clean data from day one.
The new application is built against the documented specification. Before cutover, both systems run in parallel on real data. Discrepancies surface before the old system is retired. PCG does not do big-bang cutovers on business-critical applications.
Staff training on the new system, written documentation of how it works, and a support retainer option so PCG remains available after go-live. The goal is a team that can operate the new system without calling PCG for every question.
Can PCG migrate a VB6 application if the original developer is gone?
Yes. This is the most common situation PCG encounters on VB6 projects. The developer who built the system retired, changed careers, or passed away. The documentation ranges from thin to nonexistent. The people currently using the application can describe what it does from the outside, but nobody alive has read the code in years.
PCG starts from the source code itself. If source code is available, the audit process reconstructs what the application does from the inside out. If only a compiled executable exists, PCG works from the database schema and user interviews to reconstruct the business logic before any rebuild begins. That process takes longer and costs more, but the result is the same: a documented understanding of what the system does before migration work starts.
The technology stack PCG works in for these migrations is the same one the original VB6 systems connected to. SQL Server in every version from 6.5 forward. Access databases from every era. COM components and ActiveX controls are familiar territory for this team. So are the Crystal Reports versions that shipped alongside VB6.
How long does a VB6 to .NET migration actually take?
The honest range is 8 to 20 weeks for most applications PCG handles. A single-purpose VB6 application with a clean Access backend and good source code documentation can be migrated in 8 to 10 weeks. A large multi-module system built over 15 years by multiple developers, with no documentation and a database that has grown organically since 1998, takes closer to 20 weeks or more.
The variables that drive timeline more than anything else are documentation state and data quality. An application with a documented specification and clean relational data migrates in half the time of one where PCG has to reconstruct both from scratch. The audit phase at the beginning of every PCG migration is what makes timeline estimates reliable rather than guesses.
- Source code available
- Original developer reachable for questions
- Clean relational database
- Single application module
- Staff who can demonstrate every workflow
- No source code, compiled executable only
- No documentation
- Multiple modules built by different developers
- Data spanning decades with inconsistent formats
- Undocumented edge cases in production
How does PCG scope a VB6 migration?
PCG does not quote VB6 migrations without an audit. The cost of any migration depends on the size of the application and how well it is documented. Data cleanup requirements are scoped during the audit. That figure reflects 31 years of doing this work, not an estimate built from a sales conversation.
The audit engagement produces a written scope document with a firm project quote. Clients who want a number before the audit are getting a guess. PCG does not give guesses on work that will run a business for the next 15 years.
The comparison that matters is not migration cost versus zero. It is migration cost versus what the next emergency failure costs when the VB6 application breaks on a machine that will not run the runtime, two days before a deadline that cannot move. Schedule a free 30-minute consultation at phxconsultants.com to start the conversation.2
What happens to our data during the migration?
Data integrity is treated as non-negotiable on every PCG migration. The process runs on a copy of production data, never on live data, until the parallel testing phase confirms the new system produces correct results. Every record count is verified before and after. Every calculation the old system performed is tested against the new system's output on real historical data.
VB6 applications frequently connect to Access databases or early SQL Server versions with denormalized schemas and inconsistent data types. Records that accumulated formatting quirks over decades of manual entry are cleaned during the migration process. PCG cleans and normalizes data during migration rather than carrying the same problems into the new platform. The new system starts with data that matches what the new schema expects.
Clients receive a data migration report that documents record counts by table, any records that required manual review or correction, and the transformation rules applied. That report stays with the project documentation permanently.
Your VB6 application will not run forever.
PCG has been migrating these systems since before most of them were considered legacy. Start with a free consultation and get a firm scope and quote.
Contact PCG NowFrequently Asked Questions
1 Microsoft Visual Basic 6.0 support lifecycle documentation. Microsoft ended mainstream support in 2005 and extended support in 2008. Runtime compatibility with Windows 11 is not guaranteed and has degraded with each major OS release since Windows 10 version 21H2.
2 PCG project data, 1995 to 2026. Emergency migration engagements triggered by system failure average 40% higher cost than planned migrations of equivalent scope.
Phoenix Consultants Group | phxconsultants.com | Founded 1995.