Acumatica Disaster Recovery — Multi-Region

Most Acumatica disaster recovery conversations stop at "we take nightly backups." That is a backup strategy, not a DR strategy. Disaster recovery is about how fast you can be transacting again in a different place after the primary environment is gone — and the honest answer to that question is set months earlier, by how you replicate the SQL Server database, how you stage the application tier in a second region, and whether anyone has ever actually run the failover. This walks through the parts that matter for an Acumatica deployment specifically.

Start with RPO and RTO, not with technology

Two numbers drive every DR decision. RPO (Recovery Point Objective) is how much data you can afford to lose, measured in time — an RPO of five minutes means that after a disaster you may lose the last five minutes of transactions. RTO (Recovery Time Objective) is how long the business can be down before it hurts, from the moment of failure to the moment users are back in the system.

These are business decisions, not IT ones. Finance rarely says "we need zero data loss" once they see the cost of synchronous replication across regions. Get the CFO to sign off on real numbers — say a 15-minute RPO and a 4-hour RTO — because those numbers decide whether you need synchronous database replication (expensive, latency-sensitive) or whether asynchronous replication with a documented failover is enough.

What actually needs to fail over

An Acumatica instance is three things, and DR has to account for all three:

• The SQL Server database — this is the state. Everything else is rebuildable; this is not.
• The application tier — the IIS site, the Acumatica site folder, and the customisation packages published into it.
• Out-of-database state — the file storage if you keep attachments on disk or in blob storage rather than in the database, plus scheduled task and integration configuration.

The database is the hard part and the reason DR plans live or die. The application tier is comparatively easy: an Acumatica site can be reinstalled in the secondary region from the same installer version and pointed at the failed-over database, and your customisation packages are just files you can keep in the region ahead of time. Keep the two regions on the exact same Acumatica build number — a database restored from 2024 R1 will not open cleanly against a 2024 R2 application, and DR day is not when you discover that.

Replicating the database across regions

For a SQL Server-backed Acumatica instance, the standard tool for cross-region DR is an Always On availability group with an asynchronous-commit replica in the secondary region. Asynchronous commit is what keeps write latency on the primary sane — the primary does not wait for the remote region to acknowledge each transaction — at the cost of a small, bounded RPO if you lose the primary before the last log blocks ship.

-- Add a secondary-region replica in asynchronous-commit mode
ALTER AVAILABILITY GROUP [AcumaticaAG]
ADD REPLICA ON N'SQL-DR-REGION2'
WITH (
    ENDPOINT_URL = N'TCP://sql-dr-region2.internal:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    FAILOVER_MODE = MANUAL,          -- manual: a cross-region failover is a decision, not a reflex
    SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY),
    SEEDING_MODE = AUTOMATIC
);

Keep FAILOVER_MODE = MANUAL for the remote replica. Automatic failover across regions is almost always wrong — a transient network partition between regions should not silently promote a replica that is seconds behind and leave you split-brained. A cross-region failover is a human decision made from a runbook. If you run Acumatica on Azure SQL Database instead of SQL Server on VMs, the equivalent is an active geo-replication secondary or a failover group, with the same asynchronous, manually-triggered posture.

Staging the application tier

Do not plan to install Acumatica from scratch during an outage. Pre-stage a second application server in the DR region that already has the matching Acumatica build installed and your customisation packages present but not yet pointed at a live database. On failover you change one thing — the connection string in web.config — to point at the promoted database, then start the site.

<connectionStrings>
  <!-- DR failover: repoint at the promoted secondary, then iisreset -->
  <add name="ProjectX"
       connectionString="Data Source=sql-dr-region2.internal;
         Initial Catalog=AcumaticaDB;
         Integrated Security=SSPI;
         Persist Security Info=False;
         Pooling=true;Max Pool Size=100"
       providerName="System.Data.SqlClient" />
</connectionStrings>

If attachments live on disk rather than in the database, replicate that share to the DR region too (Azure blob geo-redundancy, or a file-sync job) — otherwise you fail over to a working system where every document link is broken. The cleaner long-term answer is to store attachments in blob storage that is already geo-redundant, so file DR is not a separate problem.

DNS, integrations, and the cutover itself

Users and integrations reach Acumatica by a hostname. Put that hostname on a DNS record with a low TTL (60–300 seconds) so that on failover you can repoint it at the DR region and have clients follow within minutes rather than hours. Remember every non-browser caller: payment gateways, e-commerce sync, EDI, and any webhook endpoints registered with third parties all point at the old address and need to follow the DNS change — or be updated explicitly.

The runbook is the deliverable

The replication and the standby server are prerequisites. The actual deliverable of a DR project is a runbook that a mid-level admin can execute under pressure without you on the phone. It should be a numbered checklist, tested by drill, not a wiki page of prose:

1. Declare the disaster and confirm the primary region is genuinely down (agreed criteria, named decision-maker).
2. Fence the primary — stop the primary IIS site and disable its SQL access so it cannot resurrect and split-brain.
3. Promote the secondary replica to primary (ALTER AVAILABILITY GROUP ... FAILOVER with data-loss acknowledgement).
4. Repoint the DR application server's connection string at the promoted database and start the site.
5. Update the DNS record to the DR region.
6. Smoke-test: log in, open a business date, release a test document, confirm integrations reconnect.
7. Notify users and integration partners; note the recovery point (last committed transaction) for the finance team.

A DR plan you have never tested is a hypothesis

The single thing that separates a real DR capability from a document is the drill. Schedule a controlled failover — promote the secondary, run the site against it, transact, then fail back — at least twice a year. Every drill finds something: a customisation package that was never copied to the DR region, a firewall rule that blocks the endpoint, an integration hard-coded to the primary hostname, a build-number mismatch. Find those on a Tuesday afternoon with the team watching, not at 3 AM when the primary region is actually gone.