Microsoft Access to SQL Server migration converts each component differently: forms become modern web or desktop interfaces, reports become SSRS or custom report layers, macros become server-side stored procedures or application logic, and VBA business logic gets re-engineered into the destination language. The data itself migrates as schema, relationships, and referential integrity intact.
Microsoft Access to SQL Server migration is a technical project before it is a business project. Developers and IT directors who inherit an Access system as the next migration target need an operational map of what happens to each component, not a strategic case for migration. This article describes that operational map. It covers forms, reports, macros, VBA, queries, relationships, and the table data itself, with the specific translation patterns PCG applies across 30 years of Access migration work.1
The strategic case for migration is documented separately in the PCG Microsoft Access Exit Strategy. This article assumes the strategic decision is already made and the technical team is now responsible for execution. The destination platform discussed here is SQL Server with a custom .NET front end, which is one of two paths PCG offers. An alternative path is migration to FireFlight Data Framework, which is covered in the executive guide.2
Why do Access components require different migration strategies?
Access bundles several distinct technical concerns inside a single file format: data storage, query logic, presentation forms, business rules in VBA, scheduled macros, reporting, and user permissions. The bundling is what made Access productive for rapid application development in the 1990s and 2000s. It is also what makes migration component-specific in 2026. Each concern needs to land in the right tier of a modern architecture, and the right tier is rarely the one Access put it in.
The data layer migrates to SQL Server. Query logic moves to SQL Server views and stored procedures. Business logic translates to either stored procedures (data-layer rules), C# application code (cross-cutting business rules), or front-end event handlers (UI-specific logic). Presentation moves to a modern .NET front end. Reporting lands in SSRS, Crystal Reports for .NET, or a web-based reporting framework depending on the operation's existing tooling.
Each tier has its own translation pattern, its own validation approach, and its own risk profile during migration. Treating the migration as a single monolithic conversion produces bad outcomes: business logic that lives in the wrong tier, performance characteristics that do not match the original, and an interface that loses the workflow advantages staff depended on in the Access environment. PCG's audit phase identifies the right destination for each piece of logic before code translation begins. Component-by-component planning is what separates migrations that produce a maintainable system from migrations that produce Access-shaped problems in a new language.2
What happens to Access forms during migration to SQL Server?
Access forms do not migrate as-is. They are rebuilt in the new front-end framework. The rebuild preserves the workflow staff use day-to-day while replacing the underlying form architecture with one that scales beyond the single-file desktop model Access was built on. Two destination patterns dominate PCG's Access form migrations.
Web front end on ASP.NET Core
Forms become Razor Pages, Blazor components, or Web API endpoints with a JavaScript front end. This pattern fits distributed users, multi-office operations, and businesses that want to retire desktop deployment overhead. Form workflow stays familiar to users. Infrastructure underneath becomes server-centric.
Modern desktop client on WPF or WinForms
Forms become WPF windows or modern WinForms with direct SQL Server connectivity through Entity Framework or ADO.NET. This pattern fits operations with specific hardware integration, offline tolerance requirements, or staff who depend on keyboard shortcuts and the form responsiveness desktop frameworks deliver. Visual presentation approximates Access more closely than web does.
The decision between web and desktop follows the same operational framework PCG uses for VB6 migration target selection: hardware integration, connectivity reliability, user distribution, deployment infrastructure capacity, and workflow form. Most Access forms migrate to web in 2026 because most Access systems lack the hardware integration that pulls VB6 toward desktop. The migration decision is made per application during the audit phase, not as a generic preference.3
Unbound forms in Access have a specific translation path. Access unbound forms are screens that do not directly correspond to a single table, often used for navigation, parameter entry, or composite views. In the destination framework, these become application-tier components built against view models or data transfer objects rather than against the database schema directly. The architectural separation that Access papered over becomes explicit, which is the change that actually delivers the maintainability improvement the migration was supposed to produce.
What happens to Access reports and what replaces them?
Access reports translate to one of three destinations depending on how the operation uses reporting. PCG's audit identifies which destination fits the existing report inventory before any translation work begins.
SQL Server Reporting Services (SSRS)
SSRS produces report layouts that approximate the Access report designer model: grouping, subtotals, page headers, parameter prompts. Reports are stored on the SSRS server, accessed through a web portal or embedded in the new application, and exported to PDF, Excel, or CSV. The migration of Access reports to SSRS is the closest to a layout-preserving conversion that any component achieves.
Web-based reporting layer
Reports become live dashboard views in the new web application, with filters, drill-downs, and export buttons replacing the static report concept. This pattern fits operations that have grown past the limitations of static layouts and want interactive reporting. Migration work is more substantial than SSRS conversion because the user model changes, but the operational benefit is correspondingly larger.
Crystal Reports for .NET
Crystal Reports for .NET handles complex pixel-perfect layouts that operations have invested in over years, particularly invoices, regulatory submissions, and customer-facing documents where the layout itself is a business requirement. The migration preserves the specific layout work while moving the rendering engine to a supported platform.
Power BI for analytical reporting
Operations with substantial analytical reporting requirements sometimes move that category of reports to Power BI rather than rebuilding them in the new application. PCG evaluates case by case based on the operational reality, the existing reporting investment, and whether Power BI licensing makes sense for the user base.
Most Access migrations involve a mixed destination strategy across the report inventory. Pixel-perfect invoices land in Crystal Reports for .NET. Operational dashboards land in the web reporting layer of the new application. Standard tabular reports land in SSRS. The mixed approach reflects the operational reality that Access reports were used for several distinct purposes, and each purpose maps to the best-fitting destination rather than to a uniform replacement.2
What happens to macros and VBA business logic?
VBA does not run in the new environment. Every piece of VBA logic gets re-engineered to one of three destinations, and the destination determines the translation pattern. PCG's audit identifies the destination for each VBA module before translation begins.
Data-layer business rules become SQL Server stored procedures or triggers. Examples include validation that runs whenever a record is saved, calculation logic that updates one table based on changes in another, audit-trail generation, and constraint enforcement that goes beyond what foreign keys and check constraints handle declaratively. Moving this logic to the database server means it runs once, in one place, regardless of which application calls it. Multiple front ends, scheduled jobs, and external integrations all see the same rules enforced consistently.
Cross-cutting business logic becomes C# application code in the new application's service layer. Examples include multi-step workflows, integration with external systems, complex pricing calculations that depend on multiple data sources, and rules that interact with the user interface. Moving this logic to the application tier means it can be unit-tested, version-controlled, and modified without touching the database schema.
UI-specific behavior becomes event handlers in the new front-end framework. Examples include form field validation, conditional visibility of controls, navigation between screens, and immediate feedback to user actions. Translation depends on the destination front end: Razor Pages handlers for ASP.NET Core, code-behind methods for WPF, or component event handlers for Blazor. Behavior staff observed in the Access form is preserved. Implementation moves to where the framework expects it.1
VBA translation is not line-by-line conversion. It is re-engineering the same business outcome in the architecture appropriate to the new platform, which is the difference between a migration that produces a maintainable system and one that produces VBA-shaped problems in a new language.
How does Access table data migrate to SQL Server with relationships intact?
The data layer is the most predictable component of an Access migration. Tables, columns, data types, primary keys, foreign keys, and relationships all have direct SQL Server equivalents. The migration runs through documented patterns rather than novel translation work.
Tables become SQL Server tables with appropriate data type mapping: Access Text becomes SQL Server NVARCHAR with explicit length, Memo becomes NVARCHAR(MAX), Number with Long Integer becomes INT, Date/Time becomes DATETIME2, Currency becomes DECIMAL with appropriate precision, and Yes/No becomes BIT. PCG documents each mapping in the migration audit so the team knows exactly how each Access column landed in SQL Server.
Relationships migrate as SQL Server foreign keys with referential integrity rules. The cascade behavior that Access enforced (cascade update, cascade delete, or restrict) translates directly to SQL Server foreign key cascade options. Composite keys, self-referencing relationships, and many-to-many junction tables all have direct SQL Server representations. The relational model that Access was built on transfers to SQL Server as a structural equivalent rather than as a re-imagined schema.4
Indexes require explicit attention during migration. Access maintains its own index strategy that is largely invisible to developers; SQL Server requires explicit index design tuned to the actual query patterns. PCG's audit captures the queries that run against each table and recommends an index strategy that matches the destination query patterns rather than mirroring the Access defaults. Performance improvements from this single change are often substantial, particularly for operations that experienced concurrency issues on Access.
Speak directly with the engineer who would scope your Access migration
A free 30-minute consultation to evaluate your Access components and the right destination for each one. No obligation, no sales handoff.
What about linked tables, queries, and complex relationships?
Three areas require explicit translation decisions that the audit phase documents before migration begins.
Linked tables in Access connect to external data sources: other Access databases, SQL Server through ODBC, SharePoint lists, Excel files, or other ODBC sources. Each linked source needs a destination strategy. Cross-Access database links typically resolve by migrating the linked database into the same SQL Server instance, replacing the link with a direct schema reference. SharePoint linked lists become integrations through SharePoint REST APIs from the application layer. ODBC links to other database systems become server-side linked servers in SQL Server or scheduled data transfer jobs depending on usage patterns.4
Saved queries translate to SQL Server in three forms depending on usage. Simple SELECT queries used for read operations become views, which are reusable, cacheable, and accessible to any application that connects to the database. Parameterized queries used in forms and reports become stored procedures with parameters, which improves performance through plan caching and enables stricter input validation. Action queries (UPDATE, INSERT, DELETE used to modify data) become stored procedures with transaction handling, which provides explicit control over atomicity and rollback behavior.
Complex relationships that Access papered over need explicit attention. Multi-value fields, lookup fields with dropdowns embedded in the table schema, and attachment fields each require deliberate translation. The multi-value field type normalizes into related tables with proper foreign keys, which is the architectural correction Access deferred. Lookup fields move from the data layer to the application layer where they belong, often as reference data tables joined in views. Attachment fields become file references to a storage location plus structured metadata in the database. PCG documents each translation in the migration audit so the team understands exactly what changed.2
How does PCG validate that nothing was lost in the migration?
Validation is a defined phase of every PCG Access migration, not an assumption made after cutover. The validation approach runs through three layers, each one designed to catch a specific category of issue before the migration is declared complete.
Pre-migration baseline
Captured before any data moves
- Record counts by table, captured from the live Access database
- Aggregate calculations (sums, averages, max, min) on key numeric columns
- Reference integrity counts (orphan records, broken foreign keys identified)
- Query result baselines for the queries the application depends on
- Form behavior documented for the key workflows the team uses daily
- Report outputs archived as PDFs for layout comparison
Post-migration validation
Run before cutover is declared
- Record counts compared to baseline, any deltas explained and approved
- Aggregate calculations compared to baseline, deltas traced to translation rules
- Reference integrity verified in SQL Server, orphans resolved or documented
- Query results validated against baseline for application-critical queries
- Form behavior validated through user acceptance testing on real workflows
- Report outputs compared to archived PDFs for layout and data accuracy
The validation report is delivered as part of the migration deliverable. Any team that needs to audit the migration afterward, whether internal IT, an external auditor, or the business owner, has a documented reconciliation of what was in Access and what landed in SQL Server.
The parallel operation phase complements the validation. PCG runs the new SQL Server backend alongside the existing Access system during a transition period, with users gradually moving to the new front end while Access remains available as a fallback. Any discrepancy that surfaces during parallel operation is investigated and resolved before the Access system is retired. The fallback option means the business is not exposed to a single risky cutover moment.2
Find out what your Access components actually look like under audit
A free 30-minute consultation, followed by a fixed-fee technical audit if it is the right next step.
Technically yes, through ODBC linked tables that connect the existing Access forms to the new SQL Server backend. PCG calls this pattern a split-frontend migration, and it is sometimes used as a stepping stone rather than a final destination. The forms work, but the architectural problems that drove the migration in the first place remain partially unsolved. Full migration to a modern .NET front end on SQL Server resolves the issues that linked tables only postpone.
VBA does not run in the new environment. Each piece of VBA logic gets translated to one of three destinations during migration: server-side SQL Server stored procedures for data-layer rules, C# application code for business logic that lives in the application tier, or UI event handlers in the new front-end framework. The translation is not line-by-line conversion. It is re-engineering the same business outcome in the architecture appropriate to the new platform.
Access saved queries translate to SQL Server in three forms depending on usage. Simple SELECT queries become views. Parameterized queries become stored procedures. Action queries (UPDATE, INSERT, DELETE) become stored procedures with appropriate transaction handling. The query logic is preserved. The performance and concurrency characteristics improve significantly because SQL Server executes the queries on the server rather than pulling data to the client like Access did.
Each linked table source migrates differently. ODBC links to other database systems become server-side linked servers or scheduled data transfers in SQL Server. SharePoint linked lists become integrations through SharePoint REST APIs from the application layer. Cross-Access database links typically resolve by migrating the linked database into the same SQL Server instance. PCG evaluates each linked source case by case during the audit phase rather than committing to a generic approach.
Incremental migration is possible and frequently preferable. PCG migrates the database tables first while the Access front end continues to operate through linked tables. The application layer then migrates module by module, with users transitioning to the new interface gradually. This phased approach reduces risk and allows the team to validate each module before retiring the corresponding Access component. Full cutover is reserved for smaller systems where phased migration adds more complexity than it removes.
1 Phoenix Consultants Group, Microsoft Access Solutions service overview. phxconsultants.com
2 Phoenix Consultants Group, The Microsoft Access Exit Strategy: An Executive Guide. phxconsultants.com
3 Phoenix Consultants Group, VB6 Migration Target: Desktop or Web Application? phxconsultants.com
4 Phoenix Consultants Group, Custom .NET Software Development for Mid-Sized Business. phxconsultants.com
This article is informational and reflects PCG's experience executing Microsoft Access to SQL Server migrations since 1995. It is not legal, regulatory, or technical advice for any specific situation. Translation patterns and destination decisions vary by application; the audit phase exists to determine the right approach for each system. For guidance tailored to a particular Access migration scope, 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.
Every growing business hits this moment: revenue is up, headcount is up, but no one trusts the numbers. Sales has one version of the truth, operations has another, finance has a third, and the CEO is stuck triangulating between spreadsheets, shared drives, and half-updated apps. What used to be “good enough” data becomes a drag […]