📋
Before You Begin — Please Read
This assessment covers the Production environment only. All questions about servers, databases, hostnames, firewall rules, backup configurations, and recovery procedures refer exclusively to your Production instance. Do not document test, UAT, development, or training environments unless a question specifically asks about them.
The purpose of this questionnaire is to assess your application's readiness to be moved to its proposed resiliency tier as defined in the WS4 Implementation Roadmap. Your responses will be used to identify gaps between the application's current state and the requirements of its proposed tier, and to inform the high-level implementation plan to get it there.
Who should complete this? This questionnaire requires input from both a business owner and a technical SME. Some sections (particularly H through N) require detailed technical knowledge about the application's architecture, deployment, and infrastructure. Please involve your systems administrator and/or DBA as needed before submitting.
Estimated time: 45–90 minutes depending on application complexity and how readily documentation is available. You may save a draft at any time using the button at the bottom of the page.
SECTION A
Application Identity
Basic identification and ownership — for the Production instance. Pre-populated fields should be verified and corrected if needed.
A1
Application Name *
Official name as used in agency documentation.
A2
Agency Name *
A3
Business Owner(s) *
Name, title. Individual with budget authority and decision-making responsibility for this application.
A4
Technical SME(s) *
Name, title, email. Primary technical contact who knows this application best.
A5
What other environments does this application have?
This assessment is for Production only. This question inventories your non-production environments for implementation planning purposes — it does not expand the scope of this assessment.
Would any non-production environment also need resiliency coverage?
A6
Application Business Purpose
2-3 sentences describing what this application does and who uses it.
A7
Approximate Users by Type
Enter the approximate number of users in each category. Enter 0 for types that do not apply to this application.
| User Type | Approximate Count |
|---|---|
| Internal agency staff | |
| Other state agency staff | |
| Public / external users | |
| Automated / batch (no human users) |
A9
Hours of Operation
SECTION D
Recovery Requirements
Your application's proposed tier carries defined RTO/RPO targets from the WS4 roadmap, shown pre-filled below. Confirm them, then answer the current-state questions with factual data only — no estimates.
D1
Proposed Tier RTO & RPO — Confirm or Correct *
These values come from the WS4 Implementation Roadmap. Review and confirm they are correct for this application. If wrong, select the correct values and explain.
RTO (Recovery Time Objective) — how quickly the application must be back online and operational after a failure or disaster. RPO (Recovery Point Objective) — the maximum amount of data loss acceptable, measured as a window of time. An RPO of 1 hour means you can tolerate losing up to 1 hour of transactions.
RTO (Recovery Time Objective) — how quickly the application must be back online and operational after a failure or disaster. RPO (Recovery Point Objective) — the maximum amount of data loss acceptable, measured as a window of time. An RPO of 1 hour means you can tolerate losing up to 1 hour of transactions.
WS4 Roadmap — Proposed FMO Values
Tier
—
—
Proposed RTO
—
—
Proposed RPO
—
—
Correct RTO:
Correct RPO:
D3
If this application were re-architected with reasonable investment, what is the strictest RTO and RPO it could realistically support?
This is a forward-looking question, separate from current capability. "Reasonable investment" means typical refactoring, additional licensing, or modest infrastructure changes — not a full rebuild. Answer based on what the application's architecture and vendor support would actually permit.
Strictest realistic RTO:
Strictest realistic RPO:
What would be required to reach those numbers? (optional)
D4
Has a Business Impact Analysis (BIA) been completed for this application?
A BIA quantifies the operational and financial impact of downtime and is the primary justification for the RTO/RPO targets. If one exists or is in progress, please upload it to the designated RSI WS5 SharePoint folder and provide the document name below.
Filename:
D6
Business criticality as defined by the agency *
SECTION F
Regulatory, Data Classification & Compliance
Data sensitivity and regulatory obligations that constrain resiliency design. Affects tier feasibility, data residency, encryption requirements, and what can and cannot be replicated to a secondary site.
F1
What types of sensitive, regulated, or protected data does this application process, store, or transmit? *
Select all that apply. This determines encryption requirements, data residency constraints, and what regulatory frameworks govern the resiliency design. If none apply, select "No sensitive or regulated data."
Describe any "Other sensitive data" or add context:
F2
Oregon data classification level *
Per Oregon state policy. Level 3 and Level 4 data have specific handling requirements that may affect which resiliency tier and cloud paths are permissible.
F3
Does this application have geographic data residency requirements?
Data must remain within Oregon, within CONUS, or another geographic boundary. This affects whether cloud resiliency paths (Azure West US, etc.) are permissible, or whether the secondary site must remain on-prem at Bend.
F4
Data encryption status
Encryption requirements must be preserved in the secondary site. Encrypted-at-rest data that replicates to an unencrypted volume at Bend is a compliance violation.
Encrypted at rest?
Encrypted in transit?
F5
Does this application support time-sensitive legal, regulatory, or financial functions?
e.g. payroll processing, tax filing deadlines, benefits disbursement, court-ordered reporting, emergency dispatch. Downtime during these windows can have legal or financial consequences beyond normal operational impact.
SECTION B
Hosting, Environment & Server Configuration
All server and infrastructure details for the Production environment. Your answer to B1 determines which questions apply.
B1
Hosting Model *
Select the primary model. This determines which infrastructure questions apply.
B2
Vendor Name and Platform
For SaaS applications — name the vendor and specific platform/product.
B3
Primary Server Platform *
What is the dominant platform for this application's Production servers? Select all that apply.
B4
Production Server Inventory *
One row per Production server. Include all servers supporting this application — web, app, batch, DB, integration, identity, etc. If you have many servers, use the SharePoint upload option.
| Hostname (FQDN) | Location | Role | OS Type | OS Version | CPU / vCPU | RAM (GB) | Disk (GB) | VM / Physical | IP Address |
|---|---|---|---|---|---|---|---|---|---|
All fields are required. If information is not available, consult your agency IT team before submitting — incomplete server data cannot support a resiliency implementation plan. OS Version is especially critical; "RHEL" without a version number is not sufficient.
B6
Application Technology Stack
What is this application built with? Version numbers are important — they determine hosting compatibility and upgrade path in the secondary site.
Built with — language or platform
e.g. Java, .NET / C#, Python, COBOL, PeopleSoft, Oracle APEX, SAP, custom
Version
e.g. Java 11, .NET Framework 4.8, Python 3.9, COBOL 85
B7
Cloud Connectivity?
Is this application connected to or integrated with any cloud services?
Which cloud provider(s)?
Is this a FedRAMP or GovCloud environment?
B8
Are any Production servers shared with other applications?
Shared servers create blast-radius risk and can block tier-level replication grouping — the shared app may be at a different tier.
B9
Does the application, or any of its components (app servers, batch jobs, databases, etc.), write to local disk paths that are NOT covered by the replication or backup solution?
Local writes not captured by replication are a recovery gap — that data is lost at failover. This includes log files, temp files, file uploads, generated reports, or any data written to a local path on any server in the stack.
B10
How is OS-level job scheduling handled for this application?
Local schedulers must be re-created on the secondary-site server. Enterprise schedulers are a separate dependency — the scheduler itself must be reachable from the secondary site and configured to target the secondary-site server, not the production server.
Local scheduler details — list each task/job:
Enterprise scheduler name and version:
Note: secondary-site targeting configuration for the enterprise scheduler will be addressed during implementation runbook creation.
B11
Service Accounts
List every service account this application uses. These must exist — or be provisionable — in the recovery environment before the application can start. If the account doesn't exist at Bend / secondary site, the app won't start after failover.
| Account Name (domain\account) | Domain | Function / Purpose | Privilege Level | |
|---|---|---|---|---|
B12
Can the service accounts above be created at the Bend secondary site?
A "service account" is a login the application itself uses (not a human user) — for example, an account named
Picking "Yes" requires uploading documentation that proves multi-site portability. Without uploaded proof the answer will be treated as Unknown at submit time.
svc_AppName that the app uses to read its database. If we moved this application to Bend tomorrow, could those accounts be created and used there today — without a vendor change, license re-purchase, or hardware swap?Picking "Yes" requires uploading documentation that proves multi-site portability. Without uploaded proof the answer will be treated as Unknown at submit time.
Filename:
SECTION C
Database & Data Layer
Complete database inventory for all Production databases supporting this application. Critical for RPO analysis and replication design.
C1
Production Database Inventory *
One row per database. If this application has no database, check the box below. If you have many databases, use the SharePoint upload option.
SQL Server example: Instance = MSSQLSERVER (or named instance), Database = GenTax_PROD
Oracle example: Instance = SID or service name, Database = container / PDB name
SQL Server example: Instance = MSSQLSERVER (or named instance), Database = GenTax_PROD
Oracle example: Instance = SID or service name, Database = container / PDB name
| DB Hostname (FQDN) | Hosted Location / Data Center | DB Vendor | Version | Instance Name | Database Name | Port | DB Size (GB) | Clustering / HA | VM / Physical | IP Address |
|---|---|---|---|---|---|---|---|---|---|---|
C2
Is any database OR instance shared with other applications?
This covers two common scenarios: (1) SQL Server — multiple apps on the same instance but different databases. (2) Oracle — multiple apps in the same database but different schemas. Both are findings because you cannot replicate one app's data without moving the other app's. If you are unsure, check with your DBA before submitting — this question must be answered.
C3
Is there server or VM-level clustering configured for this application?
This is separate from database-level HA captured in C1. We need to know whether the application servers themselves have any clustering, failover, or warm standby configuration. This directly affects what resiliency infrastructure work is needed at Bend.
Clustering type (select all that apply):
C4
Is database replication to a secondary-site currently configured?
This is separate from same-site HA clustering (captured in C1). This asks specifically whether Production data is being replicated to Bend or another secondary site TODAY. "No" means data recovery at the secondary site falls back to backup restore, which directly limits the achievable RPO.
Replication technology / method in use:
Replication frequency (in minutes):
minutes
C5
How is database-level job scheduling handled for this application?
DB-internal jobs (SQL Agent, Oracle DBMS_SCHEDULER, pg_cron) must exist and be configured in the secondary-site database instance. Enterprise scheduler jobs targeting the database must be re-pointed to the secondary-site instance after failover.
List each DB-internal job — name, purpose, schedule, and whether it must run at the secondary site:
Enterprise scheduler and whether it will be re-pointed to the secondary site instance after failover:
SECTION L
Network, Firewall & Load Balancing
Network configuration that must be replicated at Bend secondary site. Undocumented firewall rules, static IPs, and load balancer configs are among the most common resiliency implementation blockers — they silently break connectivity after failover without any obvious error.
L1
Are inbound and outbound firewall rules for this application documented?
Without documented rules, the secondary site firewall cannot be correctly configured. Every missing rule at Bend is an outage waiting to happen.
Filename:
L2
How are firewall rules managed?
Centrally managed rules can be pushed to the Bend secondary-site firewall from a management platform. Per-device rules require manual recreation at each firewall at Bend during a failover event.
L3
Do users and systems connect to this application by DNS name or by IP address?
DNS-based connections can be redirected to the secondary-site server by updating a single DNS record. IP-based connections break silently at failover because the secondary-site server has a different IP with no redirect mechanism.
L4
Do any Production servers use a static IP address?
Static IPs referenced in firewall rules, configs, or external systems break when servers move to a different IP range at Bend secondary site.
L5
Does any external partner, vendor, or federal system have your server IP whitelisted on their firewall?
This is the silent resiliency killer. External parties whitelist your production IP — you failover to Bend with a different IP — their firewall silently blocks you and nobody knows why. Every external integration must be verified before resiliency testing.
L6
Does THIS specific application have its own load balancer in front of it?
This question is about the load balancer for this application's traffic only — NOT the data-center-wide load balancer that everything goes through. Pick "Yes" if there is a dedicated VIP, pool, or reverse proxy configured for this application. Pick "No" if users connect directly to the application server's hostname/IP. Some legacy applications break behind a load balancer due to session handling or header issues; both presence and compatibility need to be confirmed.
Load balancer platform:
SSL/TLS termination point:
Is the LB configuration documented and portable to Bend?
Does the application support being behind a load balancer?
Health check endpoint (required for automated failover at Tier 1/2):
L7
Does the application send email (SMTP)?
L8
Does the application use file transfer services (SFTP, FTPS, AS2, MQ)?
L9
Are there network shares (UNC paths) this application reads from or writes to?
List the share paths used by this application:
Filename (if uploaded):
SECTION H
Architecture Internals
Application behavioral characteristics that determine whether the app can function within the target tier's recovery model. Requires input from a technical SME.
H1
Application architecture style *
H2
Does the application maintain stateful user sessions?
Stateful sessions require session replication or sticky routing to survive failover without user disruption. Tier 1 and 2 require this to be solved.
⚠ Stateful sessions without replication will cause user session loss during failover. This is a required design change for Tier 1 and Tier 2 targets.
H3
Are there hardcoded server names, IP addresses, database connections, or file paths anywhere in the application?
Hardcoded values break every failover — the application tries to reach the old server and fails. Check config files, connection strings, stored procedures, registry entries, and source code. Common examples: DB server IP in web.config, SMTP relay hostname in app.properties, file share UNC path in a stored procedure, database server name in a registry key.
H4
Does the application have a specific startup sequence?
If services must start in a specific order, that sequence must be documented in the application runbook so it can be followed during recovery.
Is this startup sequence documented in a recovery section of the application runbook, and is it up to date?
If the runbook exists, you will be asked to upload it in Section E (E5 — Recovery Runbook). No need to upload it twice.
H3
Does the application use a health check endpoint or heartbeat monitor?
Required for load balancer integration and automated failover orchestration (Tier 1/2).
Filename:
H4
How are users authenticated to this application?
Active Directory is a Tier 1 dependency — if AD is unavailable, all apps that require it will fail. Applications using local accounts or federated identity can survive AD outages independently.
Which Active Directory domain(s)?
Are there local application accounts as a fallback if AD is unavailable?
Where does your login system (identity provider) actually run?
Your "identity provider" is the system that handles user logins (Microsoft Entra ID, Okta, ADFS, on-prem Active Directory, etc.). If the Salem data center had an outage right now, could users still log into this application?
H3
Does this application use SSL/TLS certificates?
Server-specific certificates break failover if not portable to the secondary site.
List the certificates in use (CN/subject, type, expiration), or upload a certificate inventory:
Filename (if uploaded):
H4
Are there any end-of-life components in this application?
EOL OS, middleware, runtime, or DB version may be an implementation blocker — cannot simply replicate broken software.
H5
If the application's main server crashes, what happens?
Pick the answer closest to reality. We are asking about THIS application's server(s) only — not the data-center hardware.
H6
If the application's main DATABASE server crashes, what happens?
Pick the answer closest to reality. If the application has no database, pick "N/A".
SECTION E
Backup & Recovery Capability
Current backup state and recovery validation. Questions E1–E2 establish the factual RPO/RTO baseline. E3–E8 cover backup configuration, testing, runbook, and agent details. SaaS applications see a separate SCI track covering vendor SLA and data portability.
SCI-1
Does the vendor publish an availability / resiliency SLA?
SCI-2
What RTO / RPO does the vendor SLA commit to?
SCI-3
Does the vendor provide data export / backup access to the agency?
Can the agency extract its data independently? Important for portability and last-resort recovery.
SCI-4
Has the agency verified the vendor's resiliency capabilities in the past 12 months?
E1
What is the current backup frequency for this application's data?
Factual — what is scheduled and running TODAY in Production. The backup frequency sets the maximum achievable RPO with the current configuration.
Backup frequency (in minutes):
minutes
Or select a special case:
E2
Has a full recovery of this application ever been timed and documented?
A timed and documented recovery test is the only defensible basis for an RTO claim. If it has never been tested, that is the finding — not an estimate.
How long did the recovery take?
When was the test conducted? (month/year)
Filename:
Approximate recovery time:
Approximately when:
E3
Are application backups currently performed? *
Backup type(s) — select all that apply:
Backup storage location(s) — describe where backups are stored:
E5
Is there a documented recovery runbook for this application?
The runbook must be accessible to the team performing recovery. A runbook that exists only on a personal laptop or in someone's head is functionally unavailable during an outage.
Filename:
E6
Is there a defined and tested failover procedure?
Tier 2 and Tier 1 require automated failover. Tier 3 can use manual if completable within RTO.
E7
Is a backup agent (Commvault, ASR, or other) installed and active on the application server(s)?
The WS4 roadmap addresses Commvault vault copy gaps for T3/T4 and ASR agent coverage for cloud-path recovery. Knowing the current backup agent state is required to determine what gap work is already in flight vs. still needed for this application.
Specify the backup agent name and version:
Is the application explicitly included in the backup job scope?
Is the backup vault copy replicated to Bend?
SECTION G
System Dependencies
Every directly integrated system. One row per dependency — be thorough. These become the dependency map in your assessment report and drive SPOF analysis.
G1
Interface Applications & Integration Dependencies
Add one row per integrated system. Include upstream (feeds this app) and downstream (this app feeds). Do not list shared infrastructure here — that's G2.
| System Name | Direction | Associated DB | Integration Type | Critical? | Their Tier (if known) |
|---|---|---|---|---|---|
Filename (if uploaded):
G2
Shared infrastructure dependencies
Services used by this application that are shared across multiple systems.
G3
Would failure of any upstream dependency cause this application to fail completely?
G4
Does the application have any external or internet-facing integrations?
SECTION I
Deployment & Operations
How this application is deployed and operated. Directly determines implementation effort and automation feasibility.
I1
How is this application deployed?
Tier 1 and 2 require automated deployment. Manual-only = required design change.
I2
How long does a FULL deployment from scratch take?
Include all steps: infrastructure, software install, data migration, config, validation. This is the minimum possible RTO in a rebuild scenario.
I3
Is there Infrastructure-as-Code (IaC) for this application environment?
Terraform, ARM templates, Ansible playbooks, PowerShell DSC, etc. IaC is a prerequisite for automated failover deployment at Tier 1/2.
I4
Are there known manual post-deployment steps required after installation?
I5
Is this application monitored in production, and what tools are in use?
Monitoring agents must be re-provisioned in the secondary site. Knowing which tools are in use is sufficient for implementation planning — full agent configuration details come at implementation.
Monitoring / security agents installed (select all that apply):
I6
Is there a single person who holds critical knowledge about this application with no documented backup?
I7
Has the application experienced unplanned outages in the past 12 months?
I8
Does restarting or failing over this application require a scheduled maintenance window or change board approval?
If a restart or failover requires advance notice, vendor involvement, or change board approval, that process time adds directly to the RTO. Some Tier 1/2 targets require zero-approval automated failover — an approval gate makes that impossible.
I9
Are there regulatory or business blackout periods when this application cannot be moved or taken offline?
Tax filing deadlines, benefits disbursement cycles, legislative sessions, federal reporting windows — any period when a migration or outage would have outsized impact must be identified and avoided in the implementation schedule.
SECTION M
Licensing & Vendor Constraints
License portability and vendor constraints that affect secondary-site deployment. Node-locked licenses and vendor SLAs that do not cover failover are common blockers.
M1
Is any software component licensed per-server, per-hostname, or per-MAC address?
Node-locked licenses require procurement action before secondary-site deployment. Oracle, IBM, Adobe, ESRI are common offenders.
M2
Does the application connect to a license server at runtime?
License servers must be reachable from the secondary site or the application won't start after failover.
M3
Does the vendor's support contract explicitly allow secondary-site / failover installations?
Some vendors require separate secondary-site license. If unknown, it must be verified before secondary-site deployment.
M4
Is the current software version vendor-supported?
M5
Has the vendor been asked whether they support this application in a secondary-site configuration?
Many vendors say "supported" on paper but have never tested it and quietly exclude it from support scope. A vendor that cannot confirm support for active-passive or active-active at a secondary site is a required design change conversation before Tier 1 or Tier 2 implementation begins.
SECTION N
Migration Readiness
Practical readiness to execute the migration to the proposed tier. Known blockers identified here become required design changes in the assessment report.
N1
Is the application deployment package available and accessible?
No package = rebuild from scratch required. This directly impacts implementation timeline.
Filename:
N2
When was this application last successfully deployed to a NEW environment from scratch?
Never deployed fresh = high migration risk. The longer ago, the more institutional knowledge drift.
N3
Does a successful deployment require involvement from an external vendor or third party?
N4
Has a migration or major upgrade of this application been attempted in the past?
N5
Are there any KNOWN technical blockers to migrating this application today?
Be specific and honest — these become the Required Design Changes section of your assessment report.
N6
Are rollback procedures documented in the application runbook?
A rollback section in the runbook means the team can revert changes if a migration or recovery fails.
Filename:
SECTION K
Supporting Documentation
For each remaining document type, indicate availability and provide the SharePoint filename if uploaded. "Not Available" is a valid answer — absence of documentation is a finding.
K1
Application Documentation Inventory
For each document type below, indicate availability and provide the SharePoint filename if uploaded.