GuestDemo Mode
Demo Workspace

Sample Decision Pack / ADR

Legacy Application Modernisation — Customer Portal · ARQ-DEMO-LEGACY-MOD

Demo · Sample Decision Pack — sample data onlyYou're viewing a read-only walkthrough with structured sample agent outputs. Live AI is disabled in demo mode.
Do not enter confidential or regulated data in the public demo environment.

Export Preview

ARB-Decision-Pack-ARQ-DEMO-LEGACY-MOD

ARB Decision Pack

1. Architecture Request Summary

Request ID: ARQ-DEMO-LEGACY-MOD
Request Title: Legacy Application Modernisation — Customer Portal
Business Problem: The customer portal runs on an unsupported legacy runtime and is difficult to maintain. The team proposes a phased strangler-fig modernisation while preserving customer-facing availability.
Proposed Solution: Modernise the customer portal to a modular cloud-native application using a strangler-fig migration. Preserve customer-facing availability, migrate identity to Entra ID, and reuse existing reporting via Power BI.
Vendor/Product: In-house build (Azure or AWS target — TBD)
AI Involved: No
Data Sensitivity: Customer account/profile data (Confidential — Internal)
Hosting Model: Azure or AWS (to be confirmed as part of review)
Integrations Required: Legacy customer portal, Oracle customer database, Entra ID authentication, Power BI reporting, Downstream customer notification services
Target Go-Live: 2027-Q2
Procurement Status: Internal funding approved; cloud platform TBD

2. Agent Analysis Summary

Request Type: Application modernisation / replacement
Business Capability: Customer Engagement / Digital Self-Service
Solution Category: Cloud-native application / Re-platform
Systems Involved: Legacy customer portal, Oracle customer database, Entra ID authentication, Power BI reporting, Downstream customer notification services, Target cloud platform (Azure or AWS — TBD)
Data Involved: Customer account/profile data, Authentication data, Operational reporting data
Assumptions
  • Strangler-fig migration over approximately 9 months.
  • No full-stop cutover is planned.
  • Customer-facing availability is preserved throughout the migration.
  • Target cloud platform decision is part of this ARB review.
Complexity Score: High
Risk Score: Medium

3. Review Routing

Application Architecture
Required/Optional: Required
Rationale: Strangler-fig pattern, portal componentisation, target-state alignment.
Security / Identity
Required/Optional: Required
Rationale: Customer identity migration to Entra ID, secrets, encryption.
Data Architecture
Required/Optional: Required
Rationale: Customer data migration integrity and reconciliation.
Cloud / Infrastructure
Required/Optional: Required
Rationale: Azure vs AWS decision and platform setup.
Operations / Support
Required/Optional: Required
Rationale: SLOs, rollback, on-call for customer-facing surface.
Business Continuity
Required/Optional: Required
Rationale: Cutover plan for a customer-facing portal with no acceptable full downtime.
Data Privacy
Required/Optional: Optional
Rationale: Customer data classification and retention preservation.
Finance / Licensing
Required/Optional: Optional
Rationale: Joint TCO and legacy decommission schedule.

4. Risk Findings

Customer-facing availability during cutover
Description: A failed slice cutover could take the customer portal offline and disrupt self-service.
Severity: High
Likelihood: Medium
Suggested Control: Strangler-fig per capability; dual-write where safe; tested rollback per slice; customer comms plan.
Owner Domain: Business Continuity
Customer data migration integrity
Description: Customer account and profile data may not migrate cleanly, producing reporting and support drift.
Severity: High
Likelihood: Medium
Suggested Control: Migration test harness with row-level reconciliation; freeze windows; sign-off per data domain.
Owner Domain: Data Architecture
Hidden integration dependencies
Description: Undocumented consumers of the legacy portal (reporting, downstream notification services) may break silently after cutover.
Severity: Medium
Likelihood: High
Suggested Control: Dependency discovery (logs/network) before migration; contract tests on all known consumers; deprecation comms.
Owner Domain: Application Architecture
Customer identity and access regression
Description: Legacy portal uses local accounts; migration to Entra ID may miss edge roles or break sign-in for a subset of customers.
Severity: Medium
Likelihood: Medium
Suggested Control: Role mapping audit; pilot with shadow access checks; access review post cutover.
Owner Domain: Security / Identity
Reporting continuity
Description: Power BI reports depend on the legacy schema and may silently drift during phased migration.
Severity: Medium
Likelihood: Medium
Suggested Control: Report reconciliation per slice; retire vs re-point reports explicitly with owner sign-off.
Owner Domain: Data Architecture

5. Missing Information

Missing Items
  • Target cloud platform and hosting pattern (Azure vs AWS) with rationale
  • Dependency map for integrations and downstream reporting/notification consumers
  • Identity migration approach with Entra ID for customer accounts
  • Rollback and cutover plan per migration phase
  • Data synchronisation and reconciliation approach between legacy and modernised components
  • Operational support model and monitoring plan for the modernised portal
Questions for Requestor
  • What criteria will drive the Azure vs AWS decision and when?
  • Has a full dependency map been produced for the customer portal?
  • What is the customer identity migration approach with Entra ID?
  • What rollback criteria apply per phase cutover?
  • How will customer data be synchronised and reconciled between legacy and modernised components?
  • What is the operational support model and monitoring plan post-migration?

6. NFR Checklist

Security Questions
  • Are all identities migrated to Entra ID with MFA for elevated roles?
  • Is data at rest encrypted with managed KMS keys in the target cloud?
  • Are admin paths logged centrally?
  • Is secrets management migrated to a managed vault?
Data Privacy Questions
  • Is the data classification preserved across the migration?
  • Are retention policies enforced on the new platform?
Integration Questions
  • Are integration contracts versioned and tested for each consumer?
  • Are API gateways used to insulate consumers during cutover?
  • Are circuit breakers in place for cross-slice calls?
Operational Questions
  • Are SLOs preserved or improved versus the legacy baseline?
  • Is rollback tested per slice in a non-prod environment?
  • Is on-call ownership defined for the migrated capabilities?
  • Is a communications plan in place for each cutover window?
AI Governance Questions
  • No AI components in scope for this change.

7. Recommended Decision

Recommended Decision: More Information Required
Decision Rationale: The modernisation is necessary and the strangler-fig approach is sound, but the target cloud platform, dependency map, identity migration approach, per-phase rollback plan, data synchronisation approach, and operational support model are not yet evidenced. ARB requires these before approving.
Conditions
  • Confirm target cloud platform and hosting pattern (Azure vs AWS) with rationale.
  • Provide a dependency map for integrations and downstream reporting/notification consumers.
  • Define the identity migration approach with Entra ID for customer accounts.
  • Provide a rollback and cutover plan for each migration phase.
  • Define the data synchronisation and reconciliation approach between legacy and modernised components.
  • Provide the operational support model and monitoring plan for the modernised portal.

8. Draft ADR

ADR Title: ADR — Customer portal modernisation (strangler-fig)
Context: The customer portal runs on an unsupported legacy runtime and is difficult to maintain. Modernisation is required to preserve customer-facing availability and reduce technical debt.
Decision: More Information Required. The modernisation approach (strangler-fig migration of the customer portal to a cloud-native modular application, with customer identity migrated to Entra ID) is directionally acceptable, but is not approved pending the information listed in the conditions. Once those items are evidenced, ARB expects to move this to Approved with Conditions.
Consequences: Positive: removes unsupported runtime, modular customer portal architecture, modern identity. Negative: approximately 9-month migration risk and overlapping run-cost; mitigated by strangler-fig, contract tests, and joint TCO governance.

9. Human ARB Decision Note

This Decision Pack was generated by ARB Copilot using a human-in-the-loop agentic workflow. The Human ARB Decision must be recorded and approved by an authorized ARB decision maker before the architecture change proceeds.

ServiceNow Work Note

Copy this summary into a ServiceNow ticket, or export the full structured payload for an iPaaS / API integration.

ARB Copilot Recommendation:
Decision recommendation: More Information Required

Intake triage: Full ARB review required

Reason:
The modernisation is necessary and the strangler-fig approach is sound, but the target cloud platform, dependency map, identity migration approach, per-phase rollback plan, data synchronisation approach, and operational support model are not yet evidenced. ARB requires these before approving.

Recommended review domains:
- Application Architecture (Mandatory)
- Security / Identity (Mandatory)
- Data Architecture (Mandatory)
- Cloud / Infrastructure (Mandatory)
- Operations / Support (Mandatory)
- Business Continuity (Mandatory)
- Data Privacy (Recommended)
- Finance / Licensing (Recommended)

Conditions:
- Confirm target cloud platform and hosting pattern (Azure vs AWS) with rationale.
- Provide a dependency map for integrations and downstream reporting/notification consumers.
- Define the identity migration approach with Entra ID for customer accounts.
- Provide a rollback and cutover plan for each migration phase.
- Define the data synchronisation and reconciliation approach between legacy and modernised components.
- Provide the operational support model and monitoring plan for the modernised portal.

Missing information:
- Target cloud platform and hosting pattern (Azure vs AWS) with rationale
- Dependency map for integrations and downstream reporting/notification consumers
- Identity migration approach with Entra ID for customer accounts
- Rollback and cutover plan per migration phase
- Data synchronisation and reconciliation approach between legacy and modernised components
- Operational support model and monitoring plan for the modernised portal
- What criteria will drive the Azure vs AWS decision and when?
- Has a full dependency map been produced for the customer portal?
- What is the customer identity migration approach with Entra ID?
- What rollback criteria apply per phase cutover?
- How will customer data be synchronised and reconciled between legacy and modernised components?
- What is the operational support model and monitoring plan post-migration?

Suggested next step:
Return request to submitter for missing information, then route to mandatory review domains.

Source request: ARQ-DEMO-LEGACY-MOD — Legacy Application Modernisation — Customer Portal

Ready to run this on your own request?

Sign in to run live AI analysis on your architecture requests, or talk to us about the ARB Copilot Design Partner Program in your own workspace.