What is custom database development, and how is it different from off-the-shelf software?
Off-the-shelf software gives every buyer the same structure. The data model, the screens, and the reports are fixed by the vendor, and your team adapts its work to fit them. Custom database development reverses that. PCG designs the database schema, the business rules, and the screens around how your operation already works, so the software fits the process rather than the process bending to the software.1
Underneath, a PCG custom database is a standard SQL Server database with a .NET application on top. That matters for a reason beyond performance: it is a documented, widely used platform, not a proprietary format only one vendor understands. The difference buyers feel day to day is that a custom database can hold the exact fields, the exact relationships, and the exact calculations the business depends on, including the ones no packaged product has a place for.2
How do you know when your business has outgrown spreadsheets and off-the-shelf tools?
The decision rarely arrives as a single event. It shows up as a pattern of workarounds that each looked reasonable on its own. A few signs appear together in most operations that have outgrown their tools:
- A spreadsheet has quietly become the system of record for a critical function, and only one or two people know how to keep it correct.
- The same data is entered in more than one place because the systems do not talk to each other, and the copies drift apart.
- Month-end reporting is a manual assembly job rather than a report the system produces on its own.
- The packaged product cannot represent a rule your business actually runs on, so the rule lives in someone's head or in a side file.
- Adding a user, a location, or a product line makes the current setup slower or more fragile rather than simply bigger.
Any one of these is tolerable. Three or more at once is the point where the cost of the workarounds has passed the cost of building the right database. PCG covers the specific versions of this pattern in the Spreadsheet Trap, the Hidden Cost of Data Silos, and what happens when one person owns the spreadsheet the business runs on.3
Custom database, configurable platform, or off-the-shelf: which fits your business?
There is no single right answer. The question is which of three paths matches the gap between what your work requires and what a product can do out of the box.
Off-the-shelf or packaged fits when
- The process is standard for your industry and rarely bends
- The reports the product ships with answer your questions
- You can live inside the vendor's data model and limits
- Integration with your other systems is light or not needed
A custom database fits when
- Your rules, fields, or reports have no place in a packaged product
- Data lives in several disconnected systems that must agree
- You need the system to connect to the rest of the business
- You want the data and its structure to stay under your control
Between those two sits a third path. A configurable platform gives you a working system faster than a full custom build while still fitting your workflow more closely than a rigid product. FireFlight Data System is PCG's configurable platform, and for many operations it is the right first step before, or instead of, a fully custom database.
Not sure if you need a configurable platform or a full custom build?
FireFlight is PCG's configurable platform for operations, inventory, compliance, and reporting. Try it for 14 days, no obligation.
What does a custom database give you that a packaged product cannot?
The value of a custom database is not more features. It is a closer fit between the system and the business, in three places that packaged products cannot reach.
Fit to your workflow
The screens, fields, and rules match how your team already works, so people enter data once, in the place the work actually happens.
Your data, connected
The database holds one version of the truth and connects to the other systems you run, so the numbers agree instead of drifting across copies.
Rules the system enforces
Validation and business logic live inside the database, so bad data is caught at entry rather than found and corrected at month-end.
That third point carries weight beyond tidy records. Gartner reported in 2026 that poor data quality or limited data availability is one of the leading direct causes of failed AI and analytics projects, ranking alongside the skills gap.4 A business that cannot trust its own data cannot build reporting, automation, or AI on top of it. A custom database puts the integrity at the foundation, where every later decision depends on it.
Who owns the database and the data when PCG builds it?
This is the question that decides how free you are later, and the answer is specific. Your data is yours. You own and control the information the system holds, and because a PCG custom database runs on standard SQL Server, that data is readable, exportable, and portable, not trapped in a proprietary format.2
The system itself is built on widely used, documented technology, SQL Server and .NET, and delivered with the documentation a technical team needs to run and extend it. That means the business is not locked to a single vendor to keep the system alive. Any qualified .NET developer can maintain it, which is the opposite of the dependence that packaged products and departed-developer situations create.5
What does the path to a custom database look like?
PCG runs the work in four phases, each producing something the business owns whether or not the next phase proceeds. The scope and schedule of each phase depend on the specific project and are set during the diagnostic, not promised in advance.
- Discovery and data audit. PCG documents how the current process works, where the data lives today, what rules the business runs on, and what reports it must produce. The deliverable is a written map the business keeps either way.
- Schema design and prototype review. PCG designs the SQL Server schema and the primary screens, then builds a working prototype for the team to review before any production development begins. Catching a mismatch on a prototype costs an hour; catching it after build costs far more.
- Build and validation. PCG builds the .NET application against the approved schema, with the business rules enforced in the database, and validates it against real workflows and representative data before it goes live.
- Migration and cutover. Existing records move into the new database with a reconciliation that confirms what left the old system arrived intact. The legacy spreadsheets or system stay available during a verification window, so the business is never exposed to a single risky switch.
When the existing system is an old database rather than spreadsheets, the same method applies. PCG covers the specific cases in the Microsoft Access Exit Strategy and in what custom .NET development looks like for a mid-sized business.
See what a system built around your data feels like.
Start a 14-day free trial of FireFlight, PCG's configurable platform, before you decide between configuring and building custom.
Frequently Asked Questions
1 Phoenix Consultants Group, Custom Database Programming service overview. phxconsultants.com
2 Phoenix Consultants Group, Custom .NET Software Development service page. phxconsultants.com
3 Phoenix Consultants Group, Tech Wisdom: Spreadsheet Trap; Hidden Cost of Data Silos; What Happens When One Person Owns the Spreadsheet. phxconsultants.com
4 Gartner, press release: "Gartner Says AI Projects in Infrastructure and Operations Stall Ahead of Meaningful ROI Returns," citing poor data quality or limited data availability as a leading direct cause of AI project failure, April 7, 2026. gartner.com
5 Phoenix Consultants Group, Tech Wisdom: My Developer Disappeared; What Do I Do? phxconsultants.com
A 2026 joint analysis by SentinelOne and Censys scanned the public internet for 293 days and found 175,000 unique Ollama instances exposed across 130 countries, most with no authentication and no firewall protection1. Many had tool-calling capabilities enabled, meaning attackers could not just consume the host's compute resources but potentially execute commands on the underlying system.
This is the part of the implementation that gets skipped most often. Ollama works perfectly on the developer's laptop with default settings. The production deployment that survives a security audit, runs as automated failover, and is tested regularly requires the steps in this article.
Why does Ollama need a firewall?
By default, Ollama binds only to 127.0.0.1:11434, which means localhost only2. This default is safe. The Ollama API is unreachable from other machines on the network, and no firewall configuration is strictly necessary.
The default changes the moment OLLAMA_HOST is set to 0.0.0.0:11434, which is required for any deployment where Ollama needs to serve requests from other machines (the most common business use case). At that point, the API is reachable from anywhere on the network. Without authentication and without a firewall, any user on the local network or, worse, any reachable internet host, can:
Submit arbitrary inference requests that pin the GPU for minutes at a time, effectively a denial-of-service attack against the host machine.
Exfiltrate model outputs by sending crafted prompts designed to leak training data or sensitive information that was used in fine-tuning.
Map the environment by querying the API for installed models, GPU specifications, and other host details that inform a larger attack.
Critical: Ollama has no built-in authentication. If OLLAMA_HOST is set to 0.0.0.0, anyone who can reach port 11434 can use the API. Firewall rules are the primary access control.
How is the firewall configured on Linux?
Linux has two common firewall tools. Ubuntu and Debian use ufw (Uncomplicated Firewall). Red Hat, CentOS, and Fedora use firewalld. Both achieve the same result with different syntax.
ufw on Ubuntu and Debian
The pattern is straightforward: deny port 11434 by default, then allow only the specific subnet or IP addresses that should have access.
firewalld on Red Hat, CentOS, Fedora
firewalld uses zones. The pattern is to add port 11434 to an "internal" zone that includes only trusted source addresses, and explicitly close that port in the "public" zone.
How is the firewall configured on Windows?
Windows uses Windows Defender Firewall. PowerShell as Administrator is the simplest way to configure rules consistently. The goal is the same: allow port 11434 only from trusted subnets.
How is the firewall configured on macOS?
macOS uses pf (Packet Filter) for firewall rules. The application firewall in System Settings does not provide enough granularity for port-level control. Editing the pf configuration directly is required.
What additional Ollama hardening matters?
Firewall rules are the first layer. Three more environment variables and configurations reduce the attack surface further.
Restrict CORS origins
Set OLLAMA_ORIGINS to the specific frontend URLs that should be allowed to call the API from a browser. This prevents arbitrary websites from making cross-origin requests to Ollama if a user visits them while on the corporate network3.
Disable the built-in web UI in production
Ollama includes a basic web UI that exposes model metadata and lacks role-based access control. Disable it in production deployments4.
Run Ollama as an unprivileged user
The official Linux installer already creates an ollama system user with no shell access. Verify this on existing installations and avoid running Ollama as root or as the primary user account. Resource limits via systemd cgroups prevent runaway processes from affecting the rest of the system.
Production hardening checklist
- Firewall rules in place restricting port 11434 to trusted sources only
- OLLAMA_ORIGINS set to specific allowed origins, not wildcard
- OLLAMA_NO_WEBSERVER=1 set to disable the unauthenticated UI
- Ollama running as an unprivileged system user, not root
- Reverse proxy with authentication in front of Ollama if accessed across networks
- Logs being collected and reviewed (see Part 3 monitoring script)
- Disk encryption at rest for the model storage directory
How does automatic failover from cloud AI to local AI work?
The architecture is simple: a thin client library sits between the application and the AI provider. Every request goes through the client. The client tries cloud AI first, and if that fails for any reason, retries the same request against local Ollama. The application code calling the client never knows which backend served the response.
The failover client handles three cases:
Connection failure
Cloud AI endpoint is unreachable, DNS fails, or TCP connection times out. Switch to Ollama immediately.
HTTP error
Cloud AI returns 5xx status code (server error) or specific 4xx codes (rate limits, service degraded). Retry with Ollama.
Timeout
Cloud AI accepts the request but takes longer than the timeout threshold. Cancel and retry with Ollama.
A working failover client in Python
The code below is the same pattern PCG uses for production deployments. It handles all three failure modes, logs which backend served each request, and exposes a single interface that drop-in replaces direct calls to the OpenAI or Anthropic SDK.
ai_request() never knows whether the response came from cloud AI or local Ollama. The failover is transparent, which is the whole point.
What is contingency mode and when does it activate?
Contingency mode is the operational state where all AI traffic routes to local Ollama by default, skipping the cloud AI attempt entirely. This is useful in two scenarios.
Known cloud outage. If the team knows the cloud provider is down (from a status page, social media, or repeated failover events in the logs), forcing contingency mode skips the wasted attempt at calling cloud AI and reduces latency for every request during the outage.
Compliance requirements. Some workflows handle data that should never touch cloud providers. Contingency mode can be enabled selectively for these workflows while other parts of the business continue using cloud AI.
Implementation is a single environment variable that the failover client checks before making any cloud request:
How often should the failover system be tested?
Quarterly at minimum. Monthly for business-critical deployments. The test is straightforward and takes about 15 minutes.
Quarterly failover drill
- Pick a low-traffic window (early morning, weekend, post-business hours)
- Block outbound traffic to the cloud AI endpoint at the firewall level for 15 minutes
- Have team members use AI-dependent workflows normally during the block
- Verify that the failover client logged "Cloud unavailable, falling back to Ollama" for every request
- Confirm response quality from local models was acceptable for the workflows tested
- Confirm monitoring alerts fired correctly (the team got notified)
- Remove the firewall block and verify automatic recovery to cloud
- Document any failures, surprises, or workflow gaps for the next iteration
Untested failover is failover that does not work when needed. The drill exists so the team finds problems in a controlled 15-minute window, not during an actual 78-minute Anthropic outage.
Does PCG build production AI continuity systems for clients?
Phoenix Consultants Group has been building production software systems for operational continuity since 1995, and three decades of experience in environments where business-critical software cannot stop translates directly to AI infrastructure. A custom AI continuity engagement covers everything in this series as a single deliverable: hardware assessment, Ollama deployment, monitoring integration, failover client development, security hardening, and team training on the contingency procedures.
The FireFlight Data System, PCG's modular platform for operational data, uses the same engineering discipline. Continuous monitoring, automatic recovery, security defaults that assume the worst, and tested procedures for every failure mode. The Ollama deployment follows that same playbook because the goal is the same: a system that works when the team needs it most.
Need a turnkey AI continuity system?
PCG handles hardware, deployment, monitoring, failover code, security hardening, and team training as one engagement. The diagnostic call is with an engineer, not a sales tier.
Frequently Asked Questions
Does Ollama need a firewall for business use?
How do I configure a firewall for Ollama on Linux?
How does automatic failover from cloud AI to local AI work?
Should failover be automatic or manual?
What is contingency mode for an AI continuity system?
How often should the failover system be tested?
Sources
1 SentinelOne and Censys joint analysis on exposed Ollama instances, early 2026: serverman.co.uk/ai/ollama/ollama-security-guide
2 Ollama default network binding documentation: github.com/ollama/ollama/blob/main/docs/faq.md
3 Ollama environment variables reference, OLLAMA_ORIGINS for CORS control: docs.ollama.com
4 Ollama production security configuration, web UI and authentication: markaicode.com/configure-ollama-firewall-rules-security
Continue Reading
Get the full security and failover guide
This is Part 4 of a 4-part series on building an AI continuity plan with Ollama. Enter your email to unlock the rest of this article including firewall configuration for Linux, Windows, and macOS, a working Python failover client, and the testing drill that keeps the system trustworthy.
We verify your email first. One click confirms your subscription.
Part 2 of this series handled hardware and installation. With Ollama running, the next questions are operational. Which model should handle which task? How does a business team know if the local AI is healthy before the moment they need it? What gets logged, and where do alerts go?
The team that treats local AI like any other production service is the team whose failover actually works during a cloud AI outage. This part covers the practices that get a deployment from "installed" to "trusted."
Which local AI model should the business use?
The honest answer is that no single model is optimal for every task. Frontier cloud models like Claude and GPT-5 are general enough that one model handles everything. Local models are typically more specialized. A practical business deployment has two or three models installed, each assigned to the task it handles best.
For general business tasks (email, documents, summaries)
Llama 3.1 8B is the most versatile general-purpose model. It runs on 8 to 12 GB of VRAM, generates 50 to 70 tokens per second on consumer NVIDIA GPUs, and produces output quality comparable to GPT-3.5 across most business workflows1. For organizations with more memory available, Llama 3.3 70B matches GPT-4 on most benchmarks and runs on 40 GB of VRAM2.
For code generation and review (Claude Code replacement)
Qwen2.5-Coder is the most capable open coding model available through Ollama. The 7B variant runs comfortably on consumer hardware and handles autocomplete, refactoring, and bug fixing. The 32B variant scores 92.7 percent on HumanEval, putting it in the same range as GPT-4o for pure coding benchmarks3.
For structured reasoning and analysis
Microsoft's Phi-4 14B is purpose-built for mathematical reasoning, structured logic, and analytical tasks. It scores 80.4 percent on the MATH benchmark and outperforms general models several times its size on STEM problems4. Phi-4 is the right pick for data analysis pipelines, algorithm design, and any task where step-by-step logical reasoning matters more than creative output.
For fast lightweight tasks
Phi-3 Mini and Gemma 2 2B are lightweight models that run on minimal hardware. They are suitable for fast text classification, simple Q&A, and tasks where response latency matters more than depth. They are not replacements for larger models but they cover the case where a task does not need full reasoning capability.
The recommended emergency library
A typical business deployment for cloud AI failover has these four models installed:
| Model | Size on Disk | VRAM Needed | Replaces |
|---|---|---|---|
llama3.1:8b |
4.7 GB | 8 GB | ChatGPT general use |
qwen2.5-coder:7b |
4.7 GB | 8 GB | Claude Code, Copilot |
phi4:14b |
9 GB | 10 GB | Data analysis, reasoning |
mistral:7b |
4.1 GB | 6 GB | Fast email/document drafting |
Total disk footprint: roughly 22 GB. Total VRAM needed if loading all at once: around 32 GB. With OLLAMA_KEEP_ALIVE set to 30 minutes and OLLAMA_MAX_LOADED_MODELS set to 2, the system loads on demand and unloads idle models, which keeps memory pressure manageable on 16 to 24 GB systems.
How are system prompts different for local AI models?
Local models follow system prompts, but they need more explicit instruction than frontier cloud models. A prompt that works perfectly on Claude may produce inconsistent results on Llama 3.1 8B. Three patterns matter.
Be direct. Frontier models infer intent. Local models follow instructions literally. Replace "Help the user with their question" with "Read the question. Provide a 3-sentence answer. Do not add disclaimers or apologies."
State the output format. If JSON is needed, say so explicitly and provide an example. If a specific length is needed, give a word count or sentence count. Vague instructions get vague results.
Forbid unwanted behaviors explicitly. Phrases like "Do not add commentary" or "Do not explain your reasoning" prevent the model from padding responses with filler. Local models tend to over-explain unless told not to.
A working system prompt template for business document drafting:
Why does monitoring matter for a failover system?
A failover that fails is worse than no failover at all. The team that built it believes coverage exists. When the cloud AI outage finally happens and the local fallback turns out to be broken, the response is slower than if they had planned for full degradation from the start.
Monitoring catches three categories of failure:
Service down. The Ollama process crashed, the systemd service stopped, the host was rebooted but Ollama did not restart, or the API port is no longer accessible.
Models missing. Disk pressure caused models to be cleaned up, a model failed to download, or the OLLAMA_MODELS directory became unmounted. The service is technically running but cannot respond to inference requests.
Performance degraded. The GPU driver was updated and is no longer detected, the system fell back to CPU inference, or the model load time has grown unacceptable. The service responds, but slowly enough that the failover is unusable.
What does a working Ollama monitoring script look like?
The script below performs three checks: API health, model availability, and a test inference. It logs results to a file and exits with a status code that integrations like cron, systemd timer, or external monitoring tools can use.
Scheduling the script
On Linux, schedule the script with cron to run every 5 minutes:
On macOS, use launchd. On Windows, use Task Scheduler. The exact configuration varies by platform, but the pattern is the same: run every 5 minutes, log to a file, and exit non-zero on failure so external monitoring can detect the problem.
How does the team get alerted when monitoring fails?
A log file no one reads is not monitoring. The script above writes to a file by design, because that file becomes the input for whatever alerting system the organization already uses. Three common patterns work.
Existing infrastructure monitoring. If the organization uses Datadog, New Relic, Prometheus, or any other monitoring stack, point it at the log file or the script exit code. The integration is one line of configuration.
Slack or Teams webhooks. A 10-line addition to the script can post to Slack or Teams when checks fail. The webhook URL goes in a config file, the script reads it, and the team gets alerts in the channel they already watch.
Email alerts via cron. Configure cron with a MAILTO header so any non-zero exit triggers an email automatically. Simplest option, no extra code required, works on every Linux system.
Does PCG help operationalize local AI deployments?
Yes. Phoenix Consultants Group has been building operational software since 1995, and the discipline that applies to monitoring legacy databases or production web services applies directly to local AI infrastructure. A custom engagement includes model selection tailored to the client's actual workflows, monitoring integration with the existing alerting stack, runbook documentation, and team training on the operational procedures.
The FireFlight Data System uses the same monitoring philosophy: continuous health checks, automatic recovery, and external alerting that catches the failures recovery does not solve. The Ollama deployment follows the same playbook.
Need monitoring built into your AI failover?
PCG designs custom monitoring and alerting for local AI deployments, integrated with your existing infrastructure.
Frequently Asked Questions
Which local AI model is best for business use?
How do I monitor whether Ollama is working correctly?
Can local AI replace Claude or ChatGPT for daily business work?
How do I write a system prompt for local AI models?
What happens if Ollama crashes during a cloud AI outage?
Should I run the monitoring script on the same machine as Ollama?
Sources
1 Llama 3.1 model documentation and benchmarks, Ollama library: ollama.com/library/llama3.1
2 Llama 3.3 70B model card and benchmark comparisons: ollama.com/library/llama3.3
3 Qwen2.5-Coder benchmarks, HumanEval 92.7 percent: ollama.com/library/qwen2.5-coder
4 Microsoft Phi-4 model card and MATH benchmark: ollama.com/library/phi4
5 Ollama API reference for /api/tags and /api/generate: github.com/ollama/ollama/blob/main/docs/api.md
Continue Reading
Get the full guide on models and monitoring
This is Part 3 of a 4-part series on building an AI continuity plan with Ollama. Enter your email to unlock the rest of this article, including the Python monitoring script and the recommended model library, plus access to all parts of the series.
We verify your email first. One click confirms your subscription.
Part 1 of this series established why every AI-dependent business needs a continuity plan and introduced Ollama as the most practical local AI runtime for that role. This part addresses the implementation. Hardware first, because every decision after it depends on hardware reality. Installation second, with the configuration choices that matter for production failover use.
By the end of this guide, Ollama will be running on the target hardware, models will be downloaded, and the foundation for a working continuity plan will be in place. The remaining two parts of the series cover model selection with monitoring, then security and auto-failover integration.
What hardware does Ollama actually need?
Ollama is software. The constraint on whether it works for a business is the hardware it runs on. Three hardware paths qualify for production use, one path does not, and the difference between them is roughly an order of magnitude in response speed.
NVIDIA GPUs (Linux and Windows)
NVIDIA is the most common business path. Ollama requires Compute Capability 5.0 or higher, which includes the GTX 960 and every NVIDIA card released since 20151. The driver version must be 535 or higher on Linux, or 531 or higher on Windows. Modern data center cards (A100, H100, L40S) work and provide significant headroom for larger models.
Verification is a single command. Run nvidia-smi in a terminal. The output shows the driver version and lists available GPUs. If the command is not found or shows errors, the driver is missing or outdated and must be installed before Ollama will use GPU acceleration.
Apple Silicon (M1 through M4)
Apple Silicon is the simplest path. M1, M2, M3, and M4 chips all support Ollama through Metal GPU acceleration with zero configuration2. Install Ollama and it uses the GPU automatically. The unified memory architecture is particularly effective for large models because GPU and CPU share the same memory pool, which means a 32 GB Mac can load models that would require dedicated 32 GB GPU cards on PC hardware.
Intel Macs are not viable. Even on a high-end Intel i9 MacBook Pro, generation speed is in the 4 to 6 tokens-per-second range, similar to CPU-only operation on PC hardware.
AMD GPUs (Linux only, as of mid-2026)
AMD support is real but limited. ROCm 7 on Linux works for most modern AMD GPUs1. ROCm on Windows is still classified as experimental and is not officially supported by Ollama. Organizations standardized on AMD GPUs on Windows should plan around this reality, either by switching the AI workload to Linux, using WSL2 with the understanding that performance and stability vary, or running Ollama on CPU as a stopgap.
Hardware sizing by model
Different models require different amounts of memory. The table below shows the recommended hardware tier for each common model at standard quantization (Q4_K_M, which is the default in Ollama and balances quality with memory efficiency).
| Available Memory | Recommended Model | Typical Speed | Best For |
|---|---|---|---|
| 8 GB RAM (CPU only) | phi3:mini or gemma2:2b |
3 to 8 tokens/sec | Simple Q&A only, not viable for production |
| 16 GB RAM (CPU only) | llama3.1:8b |
5 to 10 tokens/sec | Still too slow for most workflows |
| 8 to 12 GB VRAM (NVIDIA) | llama3.1:8b, qwen2.5-coder:7b |
50 to 70 tokens/sec | Email, documents, code generation |
| 16 GB unified memory (Apple) | llama3.1:8b |
40 to 60 tokens/sec | General business workflows |
| 24 GB VRAM (RTX 3090, 4090, A5000) | qwen2.5-coder:14b, llama3.1:70b (tight) |
30 to 100 tokens/sec | Complex reasoning, near-frontier quality |
| 48 GB+ VRAM or 64 GB+ unified | llama3.1:70b with headroom |
20 to 50 tokens/sec | Highest-quality local inference |
The pattern in the table is consistent: GPU acceleration delivers roughly 10x to 20x faster generation than CPU-only operation. For business failover, only the GPU rows are viable.
Should the organization self-host or stick with cloud AI?
Not every organization should build local AI infrastructure. The hardware investment and engineering time matter. A practical decision framework looks at three factors.
Existing hardware. If the team already runs machines with compatible GPUs (developer workstations with NVIDIA cards, Apple Silicon laptops, or Linux servers with discrete GPUs), the marginal cost of adding Ollama is engineering time only. If no suitable hardware exists, the conversation shifts to whether a continuity plan justifies a hardware purchase.
Operational criticality. If the business pauses meaningfully when cloud AI fails (development teams blocked, customer support degraded, content production stopped), local AI failover is justified. If AI use is exploratory or non-critical, the case for local infrastructure is weaker.
Data sensitivity. Organizations handling regulated data (healthcare, legal, financial) often need local AI for reasons beyond continuity. Local execution keeps prompts and responses inside the corporate network, which simplifies GDPR, HIPAA, and SOC 2 compliance.
How is Ollama installed on macOS?
macOS is the fastest path to a working installation. The graphical installer handles everything, including the system service setup that makes Ollama available after restart.
Download the macOS installer
Visit ollama.com and download the macOS package. The download is approximately 200 MB.
Run the installer and grant permissions
Open the downloaded file and drag Ollama to the Applications folder. Launch Ollama. macOS prompts for permission to install the command-line tools. Approve the prompt. Ollama now runs as a menu bar application and starts automatically at login.
Verify the installation
Open Terminal and run the verification commands:
If both commands succeed, Ollama is installed and the API server is listening. The next step is downloading a model.
How is Ollama installed on Linux?
Linux installation requires a few more steps than macOS, but the result is a more robust production deployment. The official installer creates a systemd service with automatic restart on failure, which is the right baseline for business use.
Run the installer
Execute the one-line install script. The script handles dependency detection, GPU driver verification, and systemd service creation:
The installer creates an ollama system user and installs the binary to /usr/local/bin/ollama. Model storage defaults to /usr/share/ollama/.ollama/models.
Verify the service is running
Check the systemd service status:
Configure environment variables for production use
The default installation binds Ollama to localhost only and stores models in the system partition. For production deployments, these defaults often need adjustment. Edit the systemd service:
Add the configuration under the [Service] section. The most common production variables:
Save the file and reload the service:
Confirm GPU detection (NVIDIA only)
If the machine has an NVIDIA GPU, verify Ollama is using it:
The output should mention CUDA initialization and list the detected GPU. If it shows CPU mode despite an installed GPU, the driver version is likely below the minimum (535 on Linux). Update the NVIDIA driver and restart.
How is Ollama installed on Windows?
Windows installation uses an MSI installer or the winget package manager. Both produce the same result: Ollama running as a system tray application with the API server listening on localhost:11434.
Install Ollama
Two paths work. Either download the MSI from ollama.com and run it, or install via PowerShell with winget:
The installer adds Ollama to the system PATH and starts the background service.
Verify the installation
Open a new PowerShell or Command Prompt window (a new session is required for PATH updates to take effect):
Both should succeed. The Ollama system tray icon should also be visible.
Configure environment variables
Ollama on Windows reads environment variables from the user and system environment. Quit Ollama from the system tray, then open System Properties through the Settings app or Control Panel. Add environment variables:
OLLAMA_HOST=0.0.0.0:11434(only with firewall in place)OLLAMA_MODELS=D:\OllamaModels(redirect to larger drive)OLLAMA_KEEP_ALIVE=30m
Restart Ollama from the Start menu. The new environment variables take effect on the next launch.
How are models downloaded and tested?
With Ollama installed and running, the next step is pulling the model library that the failover system will use. Pull all models during normal operations, while the network is available. Once downloaded, models live locally and require no internet access to run.
Test each model with a real prompt to confirm output quality and response speed before relying on it for failover:
A well-functioning installation responds within seconds and produces coherent output. If response time exceeds 30 seconds for a short prompt on a GPU-equipped machine, the model is probably running on CPU. Verify GPU acceleration is active.
Does PCG handle Ollama deployment for clients?
Phoenix Consultants Group has been deploying production software systems since 1995, and the operational discipline that applies to legacy migrations and compliance platforms applies equally to local AI infrastructure. A custom Ollama deployment engagement starts with a hardware audit (what compatible machines already exist on the network), continues through installation and configuration tailored to the client's operating systems, and ends with team training on the operational procedures that keep the failover ready.
The same engineering team that builds and maintains the FireFlight Data System manages Ollama deployments. Both involve infrastructure that has to run continuously without manual babysitting, which is what PCG has built for three decades.
Need help deploying Ollama in production?
PCG handles hardware assessment, multi-platform installation, monitoring integration, and team training as a single engagement.
Frequently Asked Questions
What GPU do I need to run Ollama for business use?
Can Ollama run on an AMD GPU on Windows?
How much disk space does an Ollama installation need?
Should I install Ollama as a system service or run it manually?
Where does Ollama store the downloaded models?
Do I need to keep Ollama running all the time?
Sources
1 Ollama official GPU support documentation, NVIDIA and AMD requirements: github.com/ollama/ollama/blob/main/docs/gpu.md
2 Ollama documentation on Apple Silicon and Metal GPU acceleration: docs.ollama.com
3 Ollama Linux installation and systemd configuration: docs.ollama.com/linux
4 Ollama environment variable reference: github.com/ollama/ollama/blob/main/docs/faq.md
Continue Reading
Get the full installation guide
This is Part 2 of a 4-part series on building an AI continuity plan with Ollama. Enter your email to unlock the rest of this article and receive Parts 3 and 4 covering monitoring, model selection, firewall configuration, and auto-failover integration.
We verify your email first. One click confirms your subscription.
Developers use Claude Code to write and review code. Marketing teams draft content with ChatGPT. Operations staff process documents, summarize meetings, and answer internal questions through AI assistants embedded in daily workflows. For a growing share of businesses, AI has joined email and internet access on the list of services that, when they fail, the workday effectively pauses.
Yet most organizations have no continuity plan for AI outages. Disaster recovery exists for servers, databases, and network equipment. AI is rarely included.
How often do cloud AI services actually go down?
More often than most teams realize. OpenAI's published status data shows roughly 99 percent uptime across recent 90-day windows1. Anthropic publishes comparable numbers for Claude2. A 99 percent figure sounds reassuring until the math is applied: 99 percent uptime equals roughly 7 hours of downtime per month, or 87 hours per year.
Recent major incidents make the abstract concrete. On April 28, 2026, Claude AI suffered a major outage that took down Claude.ai, Claude Code, Claude Chat, and the Anthropic API simultaneously, with more than 12,000 users filing reports on Downdetector before service restored after roughly 78 minutes3. Just 8 days earlier, on April 20, 2026, Claude had experienced a separate partial outage affecting authentication across the same surfaces3. ChatGPT experienced a major global disruption on April 20, 2026, with thousands of simultaneous reports across the UK, US, and India, affecting both the chatbot and the Codex platform4. Earlier in the year, on February 25 and 26, 2026, OpenAI logged back-to-back incidents affecting artifact generation and ChatGPT Apps integrations5. Across the same 90-day window, monitoring services tracked 134 Claude incidents and 54 ChatGPT incidents, with median recovery times measured in hours, not minutes6.
The pattern is consistent: outages happen, they last hours, and they often hit multiple platforms simultaneously because shared infrastructure underlies them all.
What does an AI outage actually cost a business?
The visible cost is paused work. A development team that has restructured around Claude Code suddenly cannot get code review, suggestions, or refactoring assistance. A marketing team that drafts and edits with ChatGPT loses its content pipeline. Customer support teams that route initial responses through AI have to fall back to fully manual workflows.
The hidden cost is the recovery time after service restores. Teams often spend hours debugging what they assume is their own broken code or misconfigured integrations before realizing the AI provider is the actual problem.
Silent Failures
Cloud AI does not always fail loudly. Models return empty responses, time out unpredictably, or degrade quietly while teams assume their own code is broken.
Shared Infrastructure
Most cloud AI providers rely on overlapping infrastructure layers. When Cloudflare or a major datacenter fails, multiple AI services fail together.
No Tested Fallback
Disaster recovery plans cover servers and databases. AI services rarely appear on the continuity checklist, leaving teams with no documented procedure when outages happen.
What is local AI and how does it fit into a continuity plan?
A continuity plan answers a specific question: when the primary system fails, what runs instead. For cloud AI, the answer is a parallel local AI system operating on the organization's own hardware, ready to take over critical workflows during an outage.
Local AI runs entirely on the user's hardware. No data leaves the building. No internet connection is required after initial setup. The most practical local AI runtime for business use is Ollama, an open-source platform that downloads and serves large language models on the same machine where business applications are running7.
Once installed, Ollama exposes an HTTP API on the local network that is compatible with the OpenAI API format. Business applications that currently call Claude or ChatGPT can be redirected to call Ollama instead with minimal code changes. The fallback is technical, automatic, and verifiable.
Does a local AI backup require special hardware?
Yes, and this is the part of the conversation that gets skipped most often. Ollama is free to install, but it is not magic. The models that make it useful for business work require specific hardware to run at usable speeds.
What hardware works
Ollama performs well on NVIDIA GPUs with Compute Capability 5.0 or higher (essentially NVIDIA GTX 960 and newer), Apple Silicon chips (M1 through M4), and AMD GPUs with ROCm 7 drivers on Linux8. On these platforms, a 7-billion-parameter model generates between 40 and 120 tokens per second depending on the specific hardware, which is fast enough for production use.
What hardware does not work
CPU-only operation is technically possible. Ollama will install and run on a machine with no GPU. The result, however, is between 3 and 8 tokens per second for the same 7B model8. That is too slow for any workflow that involves waiting for a response, which describes nearly all business use cases.
Older Intel Macs (pre-Apple Silicon) and AMD GPUs on Windows currently fall into the unsupported or poorly supported category. Organizations relying on either should plan around that reality before committing to a local AI implementation.
This series is built around organizations with appropriate hardware. CPU-only deployments are addressed honestly: not viable for production failover.
What does this series cover?
This is Part 1 of a four-part series on building an AI continuity plan using Ollama. Subsequent parts go deep on the technical implementation:
Part 2: Hardware Requirements and Installing Ollama. A detailed hardware decision guide, the exact GPU and driver specifications, step-by-step installation on macOS, Linux, and Windows, and the configuration variables that matter for production use.
Part 3: Choosing Models and Monitoring Your Local AI. Which model to assign to which business task, optimized system prompts for local models, and a complete Python monitoring script that runs as a scheduled task and alerts when Ollama goes unhealthy.
Part 4: Securing and Automating Your Failover. Firewall configuration for Linux, Windows, and macOS deployments. Auto-failover client code that detects cloud AI failures and routes requests to Ollama automatically. Full contingency mode procedures and the testing drills that keep the system trustworthy.
Does PCG build custom software systems like this for clients?
Phoenix Consultants Group has been building production software systems for operational continuity since 1995, with three decades of experience in environments where business-critical software cannot stop. The FireFlight Data System, a modular platform PCG developed and maintains, was designed with that same operational reality in mind: hosted on PCG infrastructure, monitored continuously, and architected so that one component's failure does not cascade through the rest.
The same engineering discipline applies to AI infrastructure. A custom AI continuity implementation involves hardware assessment, Ollama deployment, monitoring integration, failover client development, and team training on the contingency procedures. PCG handles all of it as a single engagement.
Building AI continuity for your team?
PCG designs and deploys custom failover systems for businesses dependent on cloud AI. The diagnostic call is with an engineer, not a sales tier.
Continue the Series
Want the technical implementation guide?
Parts 2, 3, and 4 cover hardware requirements, installation across macOS, Linux, and Windows, model selection, monitoring scripts, firewall configuration, and auto-failover integration. One installment per week, sent directly to your inbox.
We verify your email before sending anything. One click confirms your subscription.
Frequently Asked Questions
What is an AI continuity plan?
How often do cloud AI services like ChatGPT or Claude go down?
Can my business run AI locally without internet access?
What hardware does a local AI backup system require?
Is local AI a replacement for Claude or ChatGPT?
What does an AI continuity plan cost to set up?
Sources
1 OpenAI Status Page, 90-day uptime metrics: status.openai.com
2 Anthropic Status Page, 90-day uptime metrics: status.anthropic.com
3 Rolling Out, Claude AI outage hits 12,000 users in major disruption, April 28, 2026: rollingout.com/2026/04/28/anthropic-claude-outage-users-locked-out
4 Open Magazine, ChatGPT Hit by Major Global Outage, April 20, 2026: openthemagazine.com
5 StatusGator, OpenAI Outage History, February 2026 incidents: statusgator.com/services/openai/outage-history
6 IsDown monitoring data, 90-day incident counts for Claude and ChatGPT, May 2026: isdown.app/status/claude-ai
7 Ollama official documentation: ollama.com
8 Ollama GPU requirements and benchmarks, official documentation: github.com/ollama/ollama/blob/main/docs/gpu.md
Continue the Series
Get the technical implementation guide
Parts 2, 3, and 4 cover hardware requirements, installation, model selection, monitoring, firewall configuration, and auto-failover integration. One installment per week, sent directly to your inbox.
We verify your email before sending anything. One click confirms your subscription.
Data movement and middleware integration connect systems that were not designed to communicate: legacy databases, modern SaaS platforms, ERP systems, custom applications, and cloud services. The right approach depends on data volume, latency requirements, transactional integrity needs, and the systems' integration capabilities. PCG has performed hundreds of data transfers across three decades with zero data loss.
Almost no business in 2026 runs on a single system. An accounting platform was selected in 2014. The CRM came in later as a replacement for a homegrown contact database that staff outgrew. Inventory logic still lives in a custom Access database dating to 2008. The new cloud SaaS platform the sales team adopted last year does not talk to any of them. By the time the IT director inherits the portfolio, the integrations between these systems are a combination of manual exports, scheduled scripts that no one fully documents, and a no-code tool that handles two of the eight flows the business actually needs. The integration problem is not theoretical. It is the operational vulnerability that consumes more IT staff time than any other category of work.1
Phoenix Consultants Group has built data movement and middleware integration solutions across more than 500 production engagements since 1995, with hundreds of data transfers documented at zero data loss. This article describes the four integration patterns IT directors encounter most often, when each pattern fits, how PCG handles legacy systems without APIs, and how integrations are validated before going live. The framing is technical. Its audience is the IT director or integration architect responsible for the systems that have to talk to each other regardless of how unfriendly the source systems are.2
Why do business systems need middleware in the first place?
The need arrives at the point where two or more systems hold related data and the business cannot tolerate the manual reconciliation between them. An accounting platform holds the invoice. CRM holds the customer record. Fulfillment system holds the shipping status. When a customer calls about an order, the staff member needs all three. Without integration, that staff member opens three browser tabs, looks up the customer in each system, and reconciles the information mentally on the call. Multiplied across hundreds of calls per week, the manual reconciliation becomes the operational cost the business is trying to eliminate.
Middleware is the architectural answer to that cost. Instead of every system needing to know about every other system directly, middleware sits between them and handles the translation, transport, and reliability concerns. The accounting platform talks to the middleware. CRM does the same. So does the fulfillment system. When a new system joins the portfolio, it connects to the middleware once, not to each of the existing systems individually. That decoupling is what makes integration portfolios maintainable as the business grows past three or four systems.3
Without middleware, integrations are typically built as point-to-point connections: system A talks directly to system B. That works for the first integration. It becomes unmaintainable by the time the business has five systems and ten point-to-point connections, each one with its own error handling, format conversion, retry logic, and ownership. Middleware replaces that mesh with a hub model where each system has one connection to maintain rather than several.
What are the four primary patterns for moving data between systems?
Most integrations PCG builds use one of four patterns, each fitting a specific combination of data volume, latency requirement, and source system capability. The choice between patterns is made during the audit phase, not based on a default preference. Some integrations use a combination of patterns when different parts of the data flow have different characteristics.
Scheduled ETL or ELT
Bulk transfer of data between systems on a scheduled cadence: overnight, hourly, or aligned to business events. The pattern fits data warehousing, reporting refreshes, and operational synchronization where latency of minutes or hours is acceptable. SQL Server Integration Services (SSIS) and custom .NET ETL jobs are the common implementation tools.
Real-time API integration
Synchronous calls between systems through REST, SOAP, or GraphQL APIs. The pattern fits customer-facing workflows where the user needs an immediate response, and works when both source and destination systems expose modern APIs. PCG builds these on ASP.NET Core Web API with HTTP client libraries handling the API calls.
Message queue or event-driven
Asynchronous communication where the source system publishes events and one or more destination systems consume them at their own pace. The pattern fits scenarios where the sender should not wait for the receiver, when multiple destination systems need the same data, or when the receiver may be temporarily unavailable. RabbitMQ, Azure Service Bus, and legacy MSMQ are common platforms.
File-based exchange
Secure file transfer of CSV, XML, EDI, or fixed-width files between systems, often through SFTP drops or watched folders. The pattern fits integrations with legacy systems that have no API, EDI partners in supply chain or banking, and batch data exchange where the source system can only export files. PCG builds the watch and process layer in custom .NET with retry and error handling.
Most production portfolios combine these patterns rather than running on a single one. A typical mid-sized business might use real-time APIs between the e-commerce platform and the order management system, scheduled ETL to refresh the data warehouse overnight, message queues to broadcast customer updates to the marketing platform and fulfillment system simultaneously, and file-based exchange for monthly statements going to the accounting partner. The middleware layer handles all four patterns through a consistent architecture, so the IT team operates one integration platform rather than four.2
When does ETL beat real-time integration?
Real-time integration is the architecturally fashionable choice in 2026, and it produces a system that is less expensive to operate when the data flow actually requires real-time behavior. When the data flow does not require real-time behavior, real-time integration introduces complexity and operational burden that batch ETL would have avoided. The decision between the two is operational, not aspirational.
Scheduled ETL fits when
Batch behavior is acceptable
- Latency of minutes or hours does not affect business outcomes
- Source system cannot expose API or load is too high for synchronous calls
- Data volume per transfer is large (thousands or millions of rows)
- Destination system is a data warehouse, reporting platform, or analytical store
- Source system has scheduled maintenance windows that real-time would interrupt
- Integration cost must stay low and operational complexity manageable
Real-time integration fits when
Synchronous behavior is required
- User is waiting for a response that depends on the integration
- Business workflow cannot proceed until the data has crossed systems
- Both systems expose modern APIs with acceptable rate limits
- Per-transaction data volume is small (individual records, not bulk loads)
- Failure of either system needs immediate detection and alerting
- Audit trail per transaction is a compliance or operational requirement
The wrong choice in either direction has measurable cost. Real-time integration where batch would have sufficed produces operational alerts, monitoring overhead, and brittleness that batch would have avoided. Batch where real-time was required produces customer-facing latency and reconciliation work that real-time would have eliminated.
How does PCG handle integrations with legacy systems that have no APIs?
Legacy systems without APIs are the most common integration target PCG encounters in 2026. Modern integration tools assume both endpoints expose REST APIs with JSON payloads. The operational reality is that the system holding the business-critical data is often a Visual FoxPro database from 2003, a Microsoft Access application from 2008, or a mainframe extract program written before the current IT team was hired. Each one requires a different integration method.4
Direct database access is the first approach when the legacy system stores its data in a database with a known schema. ODBC drivers connect SQL Server to most legacy databases including Access, FoxPro, dBase, Paradox, and older versions of Oracle, DB2, and PostgreSQL. The middleware reads or writes through the ODBC layer, which means the legacy application does not need to be modified at all. PCG's audit phase verifies the legacy schema and identifies which tables and columns are safe to integrate against versus which require additional handling.
Scheduled file exports are the second approach when direct database access is not available or carries operational risk. The legacy system already produces reports, exports, or batch files for human review. Middleware watches the folder where those files land, picks them up automatically, parses the format, and loads the data into the destination system. This pattern has the advantage of leaving the legacy system completely untouched. The middleware sees the data only after the legacy system has already finished producing it.
Screen scraping and process automation are the third approach for systems with no programmatic interface at all. PCG uses this approach reluctantly because it is more brittle than direct database or file integration, but it works for legacy applications where the only available interface is the user interface itself. The middleware drives the legacy application through scripted interactions that mimic what a human operator would do, then captures the data the application displays. This approach fits specific situations and is documented carefully because it depends on the legacy interface remaining stable.2
The integration approach is determined by the legacy system, not by a preferred technology. PCG's audit phase identifies what each system can actually do and recommends the integration method that fits the operational reality, rather than forcing an architecture the legacy system cannot support.
What about transactional integrity when data moves across system boundaries?
Transactional integrity across system boundaries is the integration concern that distinguishes production-grade middleware from script-and-cron approaches. A flow that writes to two systems must succeed in both or roll back from both. Operations that process one record at a time must not lose records when a destination system rejects part of a batch. Updates that fan out a customer record across three downstream systems must reach a consistent state across all three, not a state where two have the update and one does not.
PCG handles transactional integrity through three design patterns depending on the flow's requirements. The first pattern is two-phase commit, which works when all participating systems support distributed transactions through XA-compatible drivers. This approach is reliable but limited to systems that expose the necessary transaction interfaces, which excludes most legacy and many SaaS systems. PCG uses two-phase commit when available and documents the trade-off when it is not. The trade-off documentation matters because the integration team has to know which guarantees the architecture actually provides versus which it approximates.
The second pattern is the saga pattern, which handles distributed transactions through compensating actions when a downstream system fails. Each integration step records what it did. If a later step fails, the middleware executes the compensating actions in reverse order to bring the systems back to a consistent state. Saga is appropriate when two-phase commit is not available and when the business can tolerate eventual consistency rather than strict atomicity.
A third pattern is idempotent message processing, which makes message queue and event-driven integrations resilient to retries. Each message carries an identifier the destination system uses to detect duplicates. If the middleware retries a message after a transient failure, the destination system processes it the first time and ignores subsequent duplicates. The pattern is the foundation of reliable asynchronous integration and PCG implements it as standard practice on message queue integrations.3
Speak directly with the engineer who would scope your integration project
A free 30-minute consultation to evaluate your current integration portfolio and the right approach for connecting the systems that matter. No obligation, no sales handoff.
How does PCG validate that integrations work correctly before going live?
Validation is a defined phase of every PCG integration engagement, not an assumption made after deployment. PCG's validation approach runs through three layers, each catching a specific category of issue before the integration reaches production traffic.
The first layer is unit testing on the transformation logic. Every format conversion, every business rule applied during the flow, and every edge case identified during the audit gets a unit test that asserts the expected behavior. The unit tests run automatically whenever the integration code changes, which means the team can refactor the integration confidently as the source or destination systems evolve. PCG delivers the unit test suite as part of the integration deliverable so the team owns the validation capability after the engagement closes.
The second layer is end-to-end integration testing against test instances of the connected systems. Where the source and destination systems offer test or staging environments, PCG runs the full integration against those environments before any production cutover. The testing exercises real data flows with realistic volumes, including failure scenarios where one of the connected systems returns errors. Issues that surface in integration testing are corrected before production deployment.
The third layer is parallel operation during the cutover period. New integration code runs alongside the existing process (manual or otherwise) for a defined verification window. PCG compares the output of the new integration against the previous process and reconciles any differences. The new integration becomes the operational master only after the team confirms the outputs match. Existing manual processes remain available as a fallback during the verification window.2
What does the data movement engagement actually look like?
PCG's data movement and middleware integration engagement runs in four phases, each producing a deliverable the business owns regardless of whether the engagement continues. The phased structure matches the patterns PCG uses across .NET migration and Access modernization work, with adaptations specific to integration projects.
Phase one is audit and integration inventory. PCG documents every system in the current integration portfolio, every manual data transfer the team performs today, every scheduled script that moves data between systems, and every no-code platform connection the business currently relies on. The deliverable is a written integration inventory the business owns as a planning asset.
Phase two is architecture and pattern selection. PCG designs the target middleware architecture, selects the integration pattern for each flow identified in the audit, and produces a phased implementation plan. The architecture document defines what the middleware layer will look like, what each connected system will see, and how the integration portfolio will evolve as new systems join the business. Pattern selection happens flow by flow, not system by system, because a single source system often participates in multiple integrations with different latency and integrity requirements.
Phase three is implementation and integration testing. PCG builds the middleware layer in custom .NET against the approved architecture, implements each integration flow according to its selected pattern, runs unit tests on transformation logic, and executes end-to-end integration tests against staging environments. Each integration is validated against representative data before it moves to the next phase.
Phase four is parallel cutover and verification. PCG deploys each integration to production in a controlled sequence, with parallel operation against existing processes during the verification window. Previous integration methods (manual exports, scheduled scripts, no-code platforms) remain available as fallback until the team confirms the new integrations match the expected outputs. The integration portfolio becomes the operational master only after verification completes.4
One platform decision sits underneath all four phases in 2026. A middleware layer is infrastructure the business runs for years, so it should not be deployed onto a runtime already approaching the end of its support window. PCG builds on the current long-term-support release of .NET, which is .NET 10, released in late 2025 and supported into 2028. The previous .NET 8 release reaches end of support in November 2026, which is why a middleware project scoped now targets the current LTS rather than the version it is about to replace.5
Find out what your integration portfolio actually requires
A free 30-minute consultation, followed by a fixed-fee integration audit if it is the right next step.
Zapier and similar no-code integration platforms work well for simple, low-volume connections between systems with native API support. They typically encounter limitations at scale: per-task pricing that scales worse than custom middleware, brittleness when one connected system updates its API, lack of transactional integrity across multi-step flows, and limited error handling for production-critical processes. PCG's approach for businesses outgrowing no-code platforms is to identify which specific integrations justify custom middleware versus which can remain in the no-code tool, then build the custom layer alongside the existing platform rather than replacing it entirely.
Yes. Legacy systems without APIs are PCG's most common integration target. The integration approach uses one of three methods depending on the system: direct database access through ODBC or native drivers, scheduled file exports from the legacy system into a watch folder, or screen-scraping and process automation for systems with no programmatic interface at all. PCG evaluates the legacy system during the audit phase and recommends the integration method that fits the system's actual capabilities.
Production integrations are built with downtime tolerance as a design requirement, not as an afterthought. Scheduled jobs use retry logic with exponential backoff. Real-time integrations queue messages during downtime and replay them when the source returns. File-based exchanges hold pending transfers in watch folders. The specific tolerance approach depends on the source system, the consequence of delayed data, and the recovery expectations the business holds. PCG documents the downtime behavior of each integration as part of the deliverable.
Format translation happens in the middleware layer, not in either connected system. Each source system produces data in its native format. The middleware layer transforms each format into the canonical structure the destination system expects. This separation means adding a new source or changing a format only requires middleware updates, not application changes. PCG has worked with XML, JSON, CSV, fixed-width flat files, EDI in all its X12 variants, and proprietary binary formats produced by legacy systems.
Yes. PCG's middleware architecture is designed for incremental integration. Each new source or destination system connects to the existing middleware layer through a documented integration contract. The contract specifies what data flows in which direction, what format the source produces, what format the destination expects, and what error handling applies. New integrations follow the same pattern as existing ones, which makes the integration portfolio extensible rather than rebuilt as it grows.
1 Phoenix Consultants Group, Hidden Cost of Data Silos: An Executive Guide to Unified Operations. phxconsultants.com
2 Phoenix Consultants Group, Data Movement and Middleware Integration service page. phxconsultants.com
3 Phoenix Consultants Group, Custom .NET Software Development for Mid-Sized Business. phxconsultants.com
4 Phoenix Consultants Group, Custom .NET vs Off-the-Shelf SaaS: A 2026 Decision Framework. phxconsultants.com
5 Microsoft, .NET and .NET Core official support policy. dotnet.microsoft.com
This article is informational and reflects PCG's experience building data movement and middleware integration since 1995. It is not legal, regulatory, or technical advice for any specific situation. Integration patterns and architecture decisions vary by portfolio; the audit phase exists to determine the right approach for each business. For guidance tailored to a particular integration scope, contact Phoenix Consultants Group directly. PCG was founded in 1995.
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.
The destination version matters in 2026. SQL Server 2025 reached general availability, and SQL Server 2016 reached the end of its support lifecycle in July 2026, so a migration planned now should target a currently supported SQL Server release rather than whatever version happens to be on hand.5 PCG scopes the target version during the audit so the new system starts well inside Microsoft's support window on both the database and the .NET runtime, which today means the current long-term-support release of .NET rather than a version already near retirement.6
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
5 Microsoft, SQL Server 2025 is Now Generally Available, and SQL Server 2016 end of support. microsoft.com
6 Microsoft, .NET and .NET Core official support policy. dotnet.microsoft.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.
Why do Excel groundwater reports stop passing regulator review around year three?
Three years is a pattern, not a hard line. What crosses it is compounding: more wells, more analytes, more frequent sampling, more sites, and rising regulator expectations, all growing at once until the total exceeds what a spreadsheet handles well. The arithmetic is simple. One site at eighty readings a year is manageable. Six sites at roughly 480 readings a year reach about 1,440 readings after three years, and about 2,400 by year five, which is the point where the spreadsheet becomes the bottleneck rather than the tool.
Two things made 2026 push programs past that line faster. Regulators now expect continuous trend visibility under RCRA corrective action, NPDES permits, and state DEP frameworks, not a plot assembled at review time. And PFAS is now firmly inside the Superfund framework: the D.C. Circuit upheld EPA's designation of PFOA and PFOS as CERCLA hazardous substances on August 18, 2026, so monitoring programs are adding PFAS analytes to their wells, which raises the volume and the stakes of every reporting cycle.1
What are the five failure modes regulators flag most often?
- Trends are invisible in static data. A pattern only appears once someone plots it by hand, which can happen too late to notify.
- Exceedance windows close before the pattern surfaces. A quarterly manual review can miss the notification window entirely.
- Cross-station analysis becomes impractical. Plume movement and treatment degradation span stations, and reconciling them across sheets by hand is too slow to keep up.
- Audit reconstruction takes days. Historical context has to be reassembled from spreadsheets, lab PDFs, and emails every time a regulator asks.
- Data-integrity gaps. Missing chain-of-custody entries, inconsistent analyte names, formula drift, and corrupted aggregation cells, which quietly compound the other four.
Regulators penalize the operational consequences of spreadsheets, not the spreadsheets themselves.
How does a missed exceedance window actually happen?
Picture a single reading that looks acceptable on its own. Plotted against the last six months it is trending toward an action level, and it matches a drift at an adjacent well. A spreadsheet hides both facts, because seeing them depends on someone deciding to look. In a common version of this, the reading sits in the file for weeks until the quarterly review, and by then the notification window has moved. Regulators read that gap as reactive monitoring, and the exposure compounds across later submissions rather than resetting each quarter.
What does cross-station trend analysis look like once Excel can no longer support it?
PCG's groundwater monitoring work produced station-by-station and analyte-by-analyte time series, supported anomaly searches, and surfaced coordinated, plume-like patterns on its own rather than waiting for an analyst to find them. The difference between the two approaches is where the work happens.
| Question | Excel-based review | Custom database |
|---|---|---|
| Who finds the pattern | Depends on the analyst looking | The system surfaces it continuously |
| Reconciliation | Manual, sheet by sheet | Handled at the database layer |
| What review covers | Whatever the review cadence catches | The whole portfolio, by default |
| When plume movement shows | During an investigation, after the fact | During routine monitoring cycles |
See continuous trend monitoring on a real platform.
FireFlight is PCG's configurable platform for operations, compliance, and reporting. Try it for 14 days, no obligation.
How does PCG move groundwater data from Excel to a custom database?
PCG runs the transition in four phases, each producing something the business keeps whether or not the next phase proceeds. The scope and schedule of each phase depend on the specific program and are set during the diagnostic, not promised in advance.
- Discovery and source auditPCG documents every Excel file, lab archive, chain-of-custody form, and regulatory framework in play, and delivers a written audit the business keeps.
- Schema design and prototype reviewPCG designs the SQL Server schema and the EHS review screens, then builds a prototype for the team to review before production work begins. A correction caught here saves far more rework than one caught after the build.
- Build and validationPCG builds a .NET 10 application on SQL Server, with recurring staff demos and user-acceptance testing against representative real data.
- Migration and parallel operationHistorical data moves across with a reconciliation report, and the Excel process and the new system run in parallel until the EHS team signs off.
What about the historical Excel data, lab PDFs, and chain-of-custody forms already accumulated?
Historical readings move into a time-series structure so trends run unbroken across the full record. Lab PDFs are stored as linked source documents, and chain-of-custody forms are kept both as source images and as queryable structured records. The original files stay accessible, and because the migration method is documented before any data moves, the migration itself is auditable. You keep and control the data throughout, in a standard format rather than a closed one.
Can the system align with multiple regulatory frameworks at the same site?
Yes. One site often sits under several regimes at once: RCRA corrective action, CERCLA Superfund, NPDES permits, EPA Title V requirements that intersect groundwater, and state DEP frameworks. Per-site configuration, the analyte lists, thresholds, and reporting requirements, is stored as data rather than written into code, so adding a site or a new threshold does not require new development. The payoff is a single cross-framework dashboard across the whole portfolio. PCG covers the field-data side of this in environmental remediation tracking and the spreadsheet origin of the problem in the Spreadsheet Trap.
Find out whether you have crossed the Excel inflection point.
Run a 14-day free trial of FireFlight and see how much of your monitoring and reporting workflow a configurable platform already covers.
Frequently Asked Questions
1 U.S. Court of Appeals for the D.C. Circuit, Chamber of Commerce v. EPA, No. 24-1193, decided August 18, 2026, upholding EPA's designation of PFOA and PFOS as CERCLA hazardous substances (final rule effective July 8, 2024). epa.gov
2 Microsoft, ".NET and .NET Core Support Policy": .NET 10 is the current long-term support release (released November 11, 2025; supported through November 14, 2028); .NET 8 reaches end of support on November 10, 2026. dotnet.microsoft.com
VB6 to .NET desktop vs VB6 to web application is decided by five operational factors: hardware integration requirements, offline operation needs, user distribution geography, deployment infrastructure capacity, and the business workflow's natural form. Most VB6 applications migrate well to web. Specific use cases continue to require desktop. The right answer depends on the operational reality, not on technology preference.
Migration from Visual Basic 6 is no longer a question of if. Microsoft ended VB6 mainstream support in 2005 and extended support in 2008, and the runtime has degraded with each major Windows release since. The current question for IT directors and CEOs running a VB6 migration project is which target platform to migrate to. Two practical options exist: a modern .NET desktop application built on WPF or current WinForms, and a web application built on ASP.NET Core with Razor Pages. Both are .NET, and both run on supported Microsoft platforms that will outlive VB6 by decades. The choice between them is not technical fashion. It is operational fit.1
PCG has been migrating VB6 applications since VB6 was current software and has executed migrations to both desktop and web targets across more than 500 production engagements in 31 years of practice. The decision framework below comes from that engagement history. It identifies the five operational factors that determine which target fits a given application, and it documents the situations where the apparently modern choice produces a system that frustrates the team that has to use it every day.2
Why does the target platform decision matter when both are .NET?
Both targets share a runtime, a language, a tooling chain, and Microsoft's long-term support commitments. Technical foundations are identical. Operational behavior is profoundly different, and the difference shows up in how the application is used every day, how it is deployed and updated, what it can connect to, and how it survives infrastructure changes.
A web application runs on a server. Users access it through a browser. Updates happen in one place. New users join by visiting a URL. Hardware access is constrained by browser security models. Operation requires connectivity between the user's device and the server. A desktop application runs on each user's machine. Updates require deployment. New users require installation. Hardware access is direct through the operating system. Operation continues when network connectivity drops. Neither set of properties is universally better. They serve different operational realities, and matching the wrong set of properties to a business's reality is the migration mistake that costs the most to fix later.
The cost of choosing wrong is not the migration cost itself. It is the cost of running a migrated application that does not fit how the business operates: workarounds that staff invent to compensate for the architectural mismatch, integrations that have to be rebuilt because the chosen platform cannot reach the hardware the workflow requires, deployment burden that the IT team did not anticipate, or connectivity dependencies that fail at the worst possible moments. Choosing the right target during the audit phase eliminates that cost entirely.2
When does VB6 to .NET desktop (WPF or WinForms) still win?
Desktop targets win when the application's operational reality includes any of three conditions. Each condition is independently sufficient. A VB6 application that hits one of them is a candidate for desktop migration regardless of how appealing the web architecture might appear in isolation.
Direct hardware integration
The application controls or reads from devices connected to the user's machine: barcode scanners, label printers, balances and scales, serial port instruments, USB measurement devices, RFID readers, or proprietary hardware with vendor-supplied SDKs. Browser security models constrain hardware access in ways that often cannot match desktop reliability.
Unreliable or absent connectivity
Users operate in environments where network connectivity is intermittent, slow, or unavailable: loading docks, warehouse floors, remote sites, vehicles in motion, or facilities where IT has not extended reliable WiFi to the operational areas. Desktop applications continue running through connectivity gaps that would freeze a web application.
Data-entry intensive workflow with keyboard shortcuts
The application supports staff doing high-volume data entry where every keystroke matters: rapid form completion, keyboard-driven navigation, custom function key mappings, and immediate field-to-field movement. Desktop interfaces still outperform browsers on raw keyboard responsiveness and shortcut customization for power users.
The first condition is the strongest signal. When a VB6 application is the only software that knows how to read the calibration data off a specific industrial balance, talk to a vendor-specific scanner through a proprietary serial protocol, or print to a label printer with a custom command set, migrating to web breaks the integration. The browser cannot reach the hardware the way the desktop application can. PCG has seen this scenario regularly across manufacturing, environmental field operations, and inventory management work where the VB6 application accumulated hardware integration over years of specific equipment purchases.3
When does VB6 to web application (ASP.NET Core) win?
Web targets win when the application's operational reality does not require any of the desktop conditions, which is the case for most VB6 applications PCG sees in 2026. Migration to ASP.NET Core with Razor Pages, Blazor, or a Web API plus modern front-end framework produces an application that is easier to deploy, easier to maintain, easier to extend, and easier to access from anywhere the business needs it.
Distributed user base
Users access the application from multiple offices, remote locations, customer sites, or home offices. Web applications eliminate the deployment and version management overhead of supporting installed software across that distribution. One server, one URL, every user current with one update.
Reporting and consultative workflows
The dominant use of the application is reading data, building reports, analyzing trends, or making consultative decisions based on what the data shows. Browsers handle these workflows comfortably, and the visualization libraries available in modern web stacks exceed what desktop frameworks deliver without significant effort.
Integration with other web services
The application needs to exchange data with cloud services, SaaS platforms, partner APIs, or other web-based systems the business operates. Web architectures handle these integrations natively. Desktop applications can do this work too, but the integration patterns are more complex and less standardized than what web frameworks make available out of the box.
The deployment advantage of web is the one that most often tips the decision for distributed businesses. A VB6 application running on 200 desktops across five offices requires IT to coordinate updates, validate installations, handle support tickets from machines that fall behind, and verify that every user is on the same version of the software. The same application as a web target updates once on the server. Every user is current the next time they refresh their browser. The IT operational burden drops materially, and the business stops having "what version of the app are you running" conversations with users who have a problem.2
What about hybrid: desktop client connecting to web services?
Hybrid architectures exist and PCG builds them when the operational reality requires them. A modern .NET desktop client that reads from local hardware and writes through a Web API to a server-side database combines the desktop strengths (hardware access, offline tolerance, keyboard responsiveness) with the web strengths (centralized data, easier reporting, simpler partner integration). This setup gives the business a single source of truth on the server while the user-facing application maintains the desktop characteristics the workflow needs.
The hybrid pattern fits situations where part of the workflow requires desktop and part requires web. Field staff capture data through a desktop client running on a tablet or laptop, with offline tolerance built in. Office staff run reports and review the captured data through a web interface against the same server-side database. Mobile users may access a third interface optimized for their devices. All three connect to the same backend data layer through Web APIs that PCG builds during the migration.
Hybrid carries additional architectural complexity, and PCG only recommends it when the operational case requires it. A single VB6 application migrated to a single target (desktop or web) is simpler to build, simpler to maintain, and simpler for the business to operate. Hybrid is the right answer when the business genuinely has two or more distinct user populations with different operational needs from the same data. When the user population is uniform, a single-target migration produces a better outcome.3
The decision is not desktop or web in isolation. It is which architecture matches the operational reality of how the business actually uses the application. PCG's audit determines that reality before recommending a target.
How do hardware dependencies in the original VB6 application affect the choice?
Hardware dependencies are the single strongest determinant of target platform selection. PCG categorizes VB6 hardware dependencies into three tiers during the audit, and each tier carries a different implication for the migration target.
First tier dependencies are direct device control: the VB6 application uses COM components, ActiveX controls, or vendor SDKs to read from or write to hardware connected to the user's machine. These dependencies almost always force a desktop target. The hardware vendor's SDK was written for Windows desktop applications, not browsers. Recreating equivalent capability in a web target typically requires either browser-side helper applications that defeat the simplification web is supposed to provide, or hardware replacement that adds significant cost and risk to the migration scope.
Second tier dependencies are network-attached hardware: printers, scanners, or measurement devices that the VB6 application reaches through TCP/IP rather than through directly-attached hardware. These dependencies can migrate to either target. A web target reaches the network-attached device the same way a desktop target does, through standard network protocols. The decision between desktop and web for these applications falls to the other four factors rather than to the hardware dependency. Network protocols are sufficiently standardized that browser-to-device communication works reliably in either architecture.
Third tier dependencies are file system access: the VB6 application reads from or writes to specific file locations, watches folders for incoming data, or generates output files for downstream systems to consume. These dependencies migrate to either target, with the web target typically using cloud storage or a controlled server-side file system rather than user-machine local files. The migration involves redesigning the file flow, which is a scope item the audit identifies and documents.1
Speak directly with the engineer who would scope your VB6 audit
A free 30-minute consultation to evaluate which target platform fits your VB6 application. No obligation, no sales handoff.
What does the target platform decision actually cost the business?
The decision affects three categories of cost across the application's productive life: build cost, deployment and maintenance cost, and operational cost.
.NET desktop migration
WPF or modern WinForms target
- Build cost comparable to web for equivalent scope
- Per-user installation and update burden ongoing
- Hardware integration preserved without redesign
- Operates through connectivity gaps without failing
- Power-user keyboard performance preserved
- Server-side infrastructure not required
- IT support model focused on user machines
Web application migration
ASP.NET Core, Razor Pages, Blazor target
- Build cost comparable to desktop for equivalent scope
- One deployment serves every user instantly
- Hardware integration limited by browser security
- Requires reliable connectivity to operate
- Visualization and reporting libraries strong
- Server-side infrastructure required and maintained
- IT support model focused on server and access
The migration cost itself is comparable between the two targets for equivalent application scope. The ongoing operational cost diverges based on user distribution, deployment frequency, and hardware integration scope.
Web applications generally produce lower ongoing IT cost for distributed user populations because deployment happens once per release rather than once per user per release. Desktop applications generally produce lower ongoing operational cost for hardware-integrated workflows because the integration does not require browser workarounds or hardware replacement. The right comparison is total cost across the productive life of the application, not the migration cost alone. PCG's audit documents both for the specific application under review.2
How does PCG make the recommendation during the audit phase?
PCG's VB6 audit produces a written target platform recommendation as part of the audit deliverable. The recommendation comes from a documented evaluation of the application against the five operational factors above, not from a default preference for either architecture. Audit deliverables include the reasoning behind the recommendation, the alternatives considered, and the trade-offs the business accepts by choosing the recommended target.
An audit phase typically completes in 2 to 3 weeks for a single-module VB6 application and longer for multi-module systems. During the audit, PCG works with the application's current users, reads the existing codebase, identifies hardware dependencies, documents the workflows the application supports, and assesses the data layer the application connects to. The target platform recommendation is the final synthesis of that work, supported by the underlying findings.
Businesses that choose to proceed with the migration use the audit document as the project specification. Those that pause after the audit own the target platform recommendation as a planning asset regardless of when migration begins. The audit is a deliverable on its own, not a commitment to a subsequent project.3
Find out which target platform fits your VB6 application
A free 30-minute consultation, followed by a fixed-fee audit that produces a written target platform recommendation.
Web is the right answer for most VB6 migrations, but not all of them. Migrating an application to web that operationally needs desktop produces a system that frustrates the team that uses it. The correct framing is not modernity. It is whether the workflow actually fits a browser interface. PCG's audit determines the answer for each application rather than defaulting to the architecturally fashionable choice.
Direct hardware integration through serial port, USB device drivers, or proprietary SDKs is the strongest single signal that desktop is the right target. Browser security models limit hardware access in ways that often cannot be worked around without compromising the operational reliability the business depends on. PCG evaluates the specific hardware in scope during the audit and recommends the architecture that preserves the integration.
Web applications require reliable connectivity to the server hosting the application. In environments where connectivity is intermittent or unavailable, desktop applications continue working while web applications fail. The decision is operational, not technical. If the field reality includes loading docks, warehouse floors, remote sites, or mobile operations where connectivity cannot be guaranteed, desktop remains the safer target.
Modern .NET desktop applications built on .NET Core 8 with WPF or current WinForms run on a supported Microsoft platform that has a long lifecycle ahead. The compatibility problems that ended VB6 came from a runtime Microsoft stopped supporting in 2008. .NET Core 8 has a documented support lifecycle through November 2026 with long-term support releases following. Choosing desktop today does not commit the business to repeating the VB6 situation.
Yes. PCG's VB6 audit produces a written recommendation on the target platform as part of the audit deliverable. The recommendation is based on the application's actual operational profile rather than a generic preference. The audit stands on its own as a planning document. The business owns the recommendation regardless of whether PCG performs the subsequent migration.
1 Microsoft Visual Basic 6.0 support lifecycle documentation. Microsoft ended mainstream support in 2005 and extended support in 2008. learn.microsoft.com
2 Phoenix Consultants Group, Visual Basic 6 Migration to .NET. phxconsultants.com
3 Phoenix Consultants Group, Custom .NET Software Development for Mid-Sized Business. phxconsultants.com
This article is informational and reflects PCG's experience executing VB6 migrations to both desktop and web targets since 1995. It is not legal, regulatory, financial, or technical advice for any specific situation. For guidance tailored to a particular VB6 migration scope, contact Phoenix Consultants Group directly. PCG was founded in 1995.
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
How has the SaaS-versus-custom decision changed in 2026?
The framework in this article has held for years. What changed in 2026 is the weight on each side of the scale, and it moved in two directions at once. Both are documented across 2026 industry research, and both belong in a CEO's calculation.
- The market is moving. Retool's 2026 State of Internal Tools report found that 35 percent of enterprises had already replaced at least one SaaS product with a custom-built alternative, and 78 percent expected to build more within two years.5 This is happening at 50-person firms, not just at large enterprises.
- AI cuts both ways. AI-assisted development has compressed custom build timelines materially, while SaaS vendors are raising prices by monetizing AI features. Industry analyses put AI-driven SaaS surcharges well above general inflation since 2024.5 The build side got cheaper and the buy side got more expensive in the same year.
- Data access became a first-order factor. An AI initiative can only reason over data it can reach. When the data that differentiates a business lives inside a SaaS product with limited export, it is data an AI tool cannot fully use. For those businesses, SaaS data lock-in stopped being a migration inconvenience and became an AI-strategy constraint.
None of this makes SaaS the wrong answer. It sharpens the question. The four situations below still decide it, but in 2026 a CEO also has to ask whether the data an AI strategy depends on is reachable inside the tools the business already rents.
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. Their integration burden, 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. For the specific variables that move a migration budget, PCG breaks them down in what drives custom software migration cost in 2026.
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, a pattern that accelerated in 2026 as vendors layered AI-feature charges on top of subscriptions.5 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.
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. Where 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
- 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
- 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 a 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, and the CEO ends the engagement owning a decision document the business uses regardless of which path is chosen. PCG's approach 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.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. Replacement is the first: 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. If the migration is off a legacy build rather than a SaaS product, the same audit-first method applies to a from-scratch custom .NET build for a mid-sized business.
Key takeaways
- SaaS is the right starting point for standard workflows, small IT teams, low user volume, and fast deployment. Most businesses should stay on SaaS.
- Custom .NET wins in four situations: logic no template fits, integration cost above license cost, pricing that scales worse than ownership at volume, and data sovereignty that rules out shared cloud. Any one is sufficient.
- In 2026 the decision shifted: Retool found 35 percent of enterprises already replaced a SaaS tool and 78 percent plan to build more, as AI made custom cheaper to build and SaaS more expensive to rent.
- Data access is now a first-order factor. An AI strategy needs to reason over operational data, and data locked in a SaaS platform with limited export is data the AI cannot fully reach.
- PCG's buy-or-build assessment is platform-neutral: it recommends SaaS when SaaS fits and quotes custom only when the audit shows custom is the cheaper long-run path.
SaaS vendors say custom is always more expensive. Is that true?
Can a custom .NET application replace multiple SaaS subscriptions?
What happens to my SaaS data when I migrate to custom?
How long does it take to move from a SaaS evaluation to a custom .NET decision?
Does AI change the SaaS-versus-custom decision in 2026?
Can PCG help evaluate whether SaaS or custom is the right choice for my business?
Sources
- Phoenix Consultants Group, Custom .NET Software Development for Mid-Sized Business (Tech Wisdom). phxconsultants.com/tech-wisdom/what-does-custom-net-software-development-actually-look-like-for-a-mid-sized-business/
- Phoenix Consultants Group, Custom .NET Software Development service page. phxconsultants.com/custom-net-software-development-that-fits-your-business/
- Phoenix Consultants Group, What Drives Custom Software Migration Cost in 2026 (Tech Wisdom). phxconsultants.com/what-drives-custom-software-migration-cost-in-2026/
- Phoenix Consultants Group, The Cost of Losing Your Business Software Source Code (Tech Wisdom). phxconsultants.com/tech-wisdom/the-cost-of-losing-your-business-software-source-code/
- 2026 build-versus-buy market data: Retool 2026 State of Internal Tools report (35% of enterprises replaced a SaaS tool; 78% plan to build more); GoodFirms 2026 Software Development Cost Survey and industry analyses of AI-driven SaaS price increases and AI-assisted development timelines.
- 1
- 2