Private System Hosting on Microsoft Azure for Banks and Lenders

Private System Hosting is the front door for any application or workload an FI needs to run that does not have a dedicated ABT product page. Calyx PointCentral has its own page. AMB Accounting has its own page. CFS Servicing Director has its own page. MortgageExchange, Mortgage BI, and Application Pilot each have their own product home. Plenty of FI software does not. That is what this page is for.

The pattern is simple. You tell us the name of the system, what it does, and roughly how many users touch it. We put together a sizing and architecture proposal, quote you on a dedicated Azure deployment, and stand it up. After cutover, your system runs alongside everything else we manage for you, in your own Azure subscription, with one identity layer, one help desk, and one monthly bill. The same engineers who run your Microsoft 365 tenant own the new workload too.

The architecture is the same architecture we use for our named-product hosting offerings. A dedicated virtual machine sized to your workload. Premium SSD for the operating system disk. Locally redundant storage (LRS) for live data, which holds three synchronous copies inside one Azure datacenter for 11 nines of durability. Geo-redundant backup (GRS) for off-site copies, which Microsoft replicates into a paired Azure region for 16 nines of durability. We do not run shared instances. We do not co-locate your data with another customer. Every deployment is single-tenant.

This is not the page for off-the-shelf SaaS that already runs in someone else's cloud. If you need to provision a Salesforce org or a HubSpot account or a Microsoft 365 tenant, the licensing channel handles that. This page is for systems that need a server somewhere and need that server to be the bank's, not a vendor's. Custom-built loan apps. Legacy on-premises platforms that have to lift to the cloud. Niche vendor software that does not have a hosted edition. File servers, internal databases, document workflow tools, and the long tail of FI-specific software you cannot find on a product brochure.

The category exists for a reason. Across our 750+ FI customer base, we get inquiries every quarter for systems that do not fit on any of our named product pages. Sometimes it is a homegrown loan-application portal a credit union built in 2014 that still works fine but the SQL Server hosting it is on hardware end-of-life. Sometimes it is a niche servicing-side workflow app that has never had a hosted edition because the vendor only has eight customers. Sometimes it is a Microsoft Access database the loan ops team has used for fifteen years that needs to come off the desktop and onto a server because four people now share it. Sometimes it is a SharePoint farm running on Server 2012 that nobody upgraded because nobody had the time. The Private System Hosting bucket is where all of those land, and the architecture is consistent across every one of them.

Three things are true at the same time and they shape how we think about this category. First, most FIs run more software than they realize. A typical community bank IT inventory has 30 to 80 distinct applications, of which maybe ten are well-known enough to have product pages. The rest are niche, custom, or legacy. Second, most of the niche/custom/legacy software at FIs runs on Windows Server with SQL Server underneath. The Microsoft stack dominates the FI software market because it always has, which means the migration target is almost always Azure. Third, the systems that lack named-product hosting are almost always the systems with the worst documentation, the oldest hardware, and the most overdue compliance work. Lifting them into a managed Azure deployment is one of the highest-value upgrade projects an IT director can run. Examiners notice. Auditors notice. The team that no longer has to keep a 2014 server alive notices most of all.

Migrations are not magic. The architecture is consistent, the runbook is documented, and the parallel-run period catches most issues, but real systems have history. Three categories of issues come up often enough that we plan for them in every standup.

Hardcoded paths and IP addresses. Older applications often have file paths, server names, database connection strings, or IP addresses baked into config files, registry keys, or even compiled code. The application worked fine on the original server because the original server happened to have those values. On Azure, the server name is different and the IP is different. We document every hardcoded reference during the scoping period and either parameterize them in the new environment or rebuild the configuration files from scratch. The parallel-run period catches the ones we missed.

Service accounts and Active Directory dependencies. Many older applications authenticate against an on-premises Active Directory using a domain service account. When the workload moves to Azure, the Active Directory dependency moves with it, but the way the application sees the directory may change. We design the new deployment to authenticate against Microsoft Entra ID where the application supports it, with a domain controller in Azure as a fallback for applications that absolutely require traditional Active Directory. The decision is made during scoping based on what the application supports.

Integrations with on-premises systems that did not move. The new system on Azure may need to talk to your core, your LOS, your servicing platform, or another system that is still on-premises. Network connectivity is not a problem (Azure ExpressRoute, site-to-site VPN, or Azure Virtual Network peering all work). The harder problem is that the old integration may have used hostnames or IP addresses that worked when both endpoints were on the same network and do not work when one endpoint is in Azure. We catch these during the parallel-run period and adjust the integration patterns before cutover.

Beyond those three, there are usually a half-dozen smaller issues that surface during testing. Print spoolers configured for a specific local print server. Scheduled tasks running as a user account that no longer exists. Backup scripts that wrote to a UNC path that is not reachable from Azure. Email notifications going to an SMTP relay that does not authenticate the new server's IP. None of these are migration-killers individually. Together, they are why we run a parallel period and why we document the runbook as we go. The parallel period also gives your team a chance to validate that the application behaves the way they expect before they depend on it for daily work.

The parallel period typically runs for one to two weeks for smaller workloads and three to four weeks for larger ones. During parallel-run, both environments are live and both are receiving data. Your team uses the new environment for some tasks and the old environment for others. ABT engineers monitor both for issues and adjust the new environment based on what we see. At the end of parallel-run, we have a documented cutover checklist with verified completion criteria. Cutover itself is usually scheduled for an after-hours window with a pre-agreed rollback plan in case something unexpected surfaces.

An FI examiner reviewing a hosted system asks the same questions every time. Where does the data live? Inside Microsoft Azure, in a US-region datacenter you select during scoping. Who has access to the underlying infrastructure? Microsoft for the platform layer, ABT for the operating system layer (with delegated admin rights to your subscription), and your designated administrators for the application layer. How is access logged? Microsoft platform logs are surfaced through Microsoft Defender for Cloud and Azure Activity Log; ABT operating-system access is logged through Microsoft Sentinel; your application access is logged by the application itself. All three feed back into your tenant where examiner requests can pull a unified timeline.

The next set of questions is about resilience. What happens if a datacenter fails? Azure storage is locally redundant by default, so a disk or rack failure does not interrupt the workload. For backup, geo-redundant storage replicates copies into a paired region in a different geography. What is the recovery point objective? Twenty-four hours by default through Azure Backup; we can shorten that with snapshots or Site Recovery if the workload requires it. What is the recovery time objective? Four to eight hours for restoration from Azure Backup; under one hour for workloads that have Azure Site Recovery layered in. When was the last restore test? Quarterly, documented in the backup test log. The schedule is part of our standard operating procedure.

The third set of questions is about vendor management. What controls does the vendor have over your data? ABT operates under SOC 2 Type II attestation covering hosting and managed-service controls. What is the vendor's incident response process? Documented in our incident response runbook, which we share under NDA. What happens if the vendor goes away? The Azure subscription is in your name. The application binaries and data belong to you. Migration to another Microsoft Cloud Solution Provider is a documented runbook handoff, not a rebuild from scratch.

The last question is the one that matters most. Is this a meaningful improvement over what was running before? For most FIs, the answer is yes for measurable reasons. Single identity layer instead of two or three. Documented patching cadence instead of best-effort. Backups in a paired region instead of a tape rotation that may or may not be working. SOC 2 attestation instead of a vendor questionnaire response. Sentinel logging instead of separate vendor logs in five places. Most of the wins compound over time as your environment matures.

The standup is the visible part of the engagement. The ongoing operation is the part that matters more over a five-year horizon. Here is what your team should expect after cutover.

Monthly patching. ABT applies operating-system patches on a documented monthly cadence aligned with Microsoft's Patch Tuesday release schedule. The maintenance window is scheduled with your team during onboarding and recurs predictably. Patches install during off-hours; rollback is available for any patch that causes an issue. Patch-related issues that surface during business hours go to the same help desk that handles the rest of your environment.

Backup verification. Azure Backup writes a snapshot every 24 hours (more frequently for transactional workloads where the recovery point objective is tighter). The backup status is monitored daily. Failed jobs trigger a help desk ticket against ABT (not against you). Quarterly restore tests validate that the backup is actually restorable; the test results land in your backup test log. Examiner requests for backup evidence pull from one folder.

Defender for Cloud review. Microsoft Defender for Cloud scores your Azure subscription on a continuous basis. ABT reviews the score against our standard baseline at least quarterly with your team. Findings are remediated against the baseline, with a documented exception process for items that genuinely cannot be remediated due to application constraints. The review meeting is short and focused; a 30-minute call covers most environments.

Help desk routing. Issues with the Private System Hosting workload route to the same help desk that handles your Microsoft 365 environment. There is no separate ticketing system for the new system. Tickets are tagged in our internal system to identify which workload they relate to, but to your team it is one inbox, one phone number, one team. Most environments fold seamlessly into the existing support relationship.

Quarterly architecture review. Once a quarter, an ABT engineer schedules a 30-minute review with your team to look at the architecture, the operational metrics, and any pending changes. Are user counts growing? Do we need to upgrade the VM tier? Are integrations performing the way we expected? Is there a feature in the application that has changed since the last review and needs attention? The review surfaces small adjustments before they become large problems.

Annual SOC 2 refresh. ABT's SOC 2 Type II attestation refreshes annually. The new attestation letter is delivered to your team within 30 days of issuance, along with a refreshed vendor management package that maps Microsoft's SOC 2, our SOC 2, and your application-layer policies. There is no separate fee for this. It is part of the managed-service relationship.

Change management. Significant changes to the architecture (a new Azure region, a hot secondary, an increase in storage tier, a change to backup retention) follow a documented change management process. Change requests are documented, approved, scheduled, and tested before they go live. Examiners reviewing your change management practices will find the records they expect to find. Smaller changes (user count adjustments, application-layer permission updates) follow a lightweight version of the same process: still documented, just faster.

The fastest scoping conversations happen when the form message gives us enough to work with. You do not need a full requirements document. You do need a few sentences that capture what the system is, what it runs on, and roughly how big it is. Three example messages, drawn from typical inquiry patterns, show what gets the conversation moving:

Example 1 (custom-built application): "We have a homegrown borrower portal a contractor built for us in 2017. ASP.NET on Windows Server 2016, SQL Server 2016 backend, about 80 GB of data, used by roughly 40 internal staff plus external borrower logins (peaks around 200 concurrent during refi rushes). Currently on a server in our HQ closet that is end-of-life next quarter. Need to lift to Azure with the same security baseline as our M365 environment. We integrate to Encompass nightly via SFTP file drop." That message has everything we need to start a sizing exercise.

Example 2 (legacy on-premises lift): "We run a niche BSA/AML scanning tool from a vendor that only has eight customers nationally. Vendor sells the binaries, no hosted edition. Runs on Server 2019 plus SQL Express. About 15 GB of data, used by 4 BSA analysts. Current server is fine but we want it off-premises and behind the same MFA layer as our M365. Vendor's license terms allow third-party hosting." That message tells us this is the "niche vendor software" category, the licensing question is already answered, and the workload is small enough to fit our XS sizing tier.

Example 3 (file server consolidation): "We have three Windows file servers (Server 2012 R2, end-of-life supported through ESU until late 2026) holding departmental shares for loan ops, accounting, and compliance. Total storage about 4 TB. Roughly 60 staff access them daily. We want to consolidate into Azure Files or a single Azure-hosted Windows file server, keep the existing NTFS permissions, and integrate with our existing Microsoft Entra ID tenant." That message has the storage volume, the user count, and the identity layer specified, so the scoping conversation can focus on whether Azure Files or a Windows file server is the better fit for the access patterns.

If your message is shorter than that, it is fine. The scoping call fills in the gaps. We just ask more questions on the call and turn the proposal around in the same one-week window. Longer is also fine. If your team has already done a requirements document, send it along. We read it and the proposal is faster.