Cathay Cargo Terminal · Enterprise Cloud Modernisation Programme

WebLogic 12.x → JBoss EAP 8
Oracle → Aurora PostgreSQL
On-prem → AWS ap-east-1

Comprehensive technical migration reference for Cathay Cargo Terminal (CCT) — covering application server modernisation, database replatforming, cloud landing zone, identity integration, and interface migration for 6 application channels across internal, external, mobile, and airline user segments at Hong Kong International Airport.

WebLogic 12.x → JBoss EAP 8 Oracle → Aurora PostgreSQL On-prem → AWS ap-east-1 Azure Entra ID OIDC/SAML SITA · ACCS · GLS · HKIA One Cathay Pacific Corporate Interfaces Jakarta EE 10 · Java 17 AWS DMS · Aurora · EKS
6
Application channels
5
External integrations
12–18
Month programme
3-axis
Concurrent migrations
scroll ↓
Section 01

Executive Summary & Business Case

CCT's current on-premises stack — WebLogic 12.x, Oracle RDBMS, and data-centre hosted integration — carries significant licensing cost, operational risk, and limits agility. This programme eliminates those constraints while preserving CCT's role as HKIA's primary cargo community operator.

High
Oracle CPU licensing cost exposure
EOS
WebLogic 12.2.1.x: extended support only from 2024
~40%
Estimated TCO reduction at steady state
<15 min
Target RTO (Aurora Multi-AZ)
99.99%
SLA target on AWS (vs on-prem 99.9%)
ap-east-1
Data residency: Hong Kong region only

Migration axes & rationale

Axis 1 — App Server

WebLogic 12.x → JBoss EAP 8

Eliminates Oracle WebLogic licensing ($50K–$300K+/CPU-core). JBoss EAP 8 is Red Hat supported, Jakarta EE 10 compliant, Java 17/21 native, and free of Oracle vendor lock-in. Runs on any Linux compute (EC2, EKS) with no per-CPU charge.

Axis 2 — Database

Oracle → Aurora PostgreSQL

Oracle CPU-based cloud licensing is prohibitively expensive on AWS. Aurora PostgreSQL offers managed Multi-AZ HA, automated backups, point-in-time recovery, and integrates natively with AWS DMS for live migration. Open-source compatibility reduces long-term DBA tool dependency.

Axis 3 — Infrastructure

On-prem → AWS ap-east-1

Cloud hosting eliminates DC hardware refresh cycles, provides elastic scaling during peak cargo seasons (e.g. pre-CNY, Black Friday air freight surges), and enables a modern DevOps pipeline with IaC, CI/CD, and observability-as-code.

As-Is vs To-Be — technology stack

As-Is
Oracle WebLogic 12.2.1.x Cluster
Managed servers on VMware ESXi · Shared JNDI · WebLogic JMS · WebLogic JDBC Stores
→
To-Be
JBoss EAP 8.0 on EC2 / EKS
Jakarta EE 10 · ActiveMQ Artemis · Elytron OIDC · Infinispan · MicroProfile Config
As-Is
Oracle RDBMS (RAC or single instance)
SAN storage · RMAN backup · Data Guard standby · PL/SQL business logic
→
To-Be
Amazon Aurora PostgreSQL (Multi-AZ)
pg_dump/DMS migration · plpgsql procs · Read replicas · Performance Insights · 35-day backup
As-Is
On-prem datacentre (HKIA / CX HQ)
Physical/virtual servers · Hardware F5 LB · AD FS / LDAP SSO · IBM MQ
→
To-Be
AWS ap-east-1 VPC (Hong Kong)
ALB · Route 53 · CloudFront · WAF · Secrets Manager · Amazon MQ · Direct Connect hybrid
As-Is
AD FS / Legacy SSO (internal)
Internal user authentication for terminal staff; Kerberos/NTLM for web
→
To-Be
Azure Entra ID (OIDC + SAML 2.0)
MFA · Conditional Access · group-based RBAC mapped to JBoss Elytron roles
Programme governance: This is a CEO/CIO-level approved programme with a dedicated Programme Manager reporting to CCT IT leadership. Active steering committee participation from Cathay Pacific CIO office, AAHK HKIA One team, and SITA integration services required throughout.
Section 02

Application Portfolio

CCT operates six distinct user-facing channels segmented by audience, network zone, and authentication model. Each maps to one or more deployable JBoss EAR/WAR units with its own security domain and database connection pool.

🏢
Internal — Corporate VPN

CCT Internal Web Application

Terminal operations for CCT staff — cargo acceptance, build-up/break-down, ULD management, warehouse floor control, supervisor dashboards, and shift reporting. Authenticated exclusively via Azure Entra ID (corporate SSO). Accessible only over CPA VPN / Direct Connect from AWS.

📱
Internal Mobile — Corporate

CCT Internal Mobile Application

Rugged-device and tablet apps for ramp, warehouse, and gate staff. Offline-capable scan-and-sync. Entra ID auth via MSAL / OAuth 2.0 device code flow. REST/JSON API backend on JBoss. Push notifications via Firebase (or SNS).

🌐
External — Internet DMZ

Agents & Freighters Portal

Public-facing web portal for freight forwarders, GSAs, and NVOCC operators. Booking enquiries, status tracking, eAWB document upload. Internet zone — separate JBoss security realm, WAF protection, rate limiting. Self-service registration with email MFA.

🚛
External Mobile — Internet

Trucker Mobile Application

Driver-facing app for truck pre-notification, gate entry/exit, e-form submission, collection queue management, and e-receipt at CCT gates. Integrates with ACCS for truck gate passes and terminal access control via NFC/QR. OAuth 2.0 mobile flow.

✈️
Airline — Federated SSO

Airline Web Application

Dedicated portal for airline users — cargo loading plans, flight manifests, cargo allocations, special handling (DG, PER, VAL) requests, and airline messaging. Role-based access per IATA airline code. Federated SSO with airline identity providers (SAML).

⚙️
Backend Services

Integration & Batch Services

MDB listeners (ActiveMQ Artemis), scheduled EJB timers, file-drop processors (S3 event-driven), and REST/SOAP adapters for SITA, ACCS, GLS, HKIA One, and Cathay Pacific corporate interfaces. Deployed as headless EAR modules on JBoss. No direct user-facing traffic.

Network zones & AWS placement

ZoneApplicationsAuth ModelAWS PlacementJBoss Cluster
Corporate / Internal CCT Internal Web, CCT Internal Mobile API Azure Entra ID (OIDC) Private subnets + ALB (internal). Direct Connect / Client VPN from CPA/CCT network. JBoss Cluster A — internal
DMZ — Internet Agents & Freighters, Trucker Mobile API, Airline Portal Local accounts + MFA; airline SSO federation (SAML) Public ALB + CloudFront + AWS WAF. Isolated VPC subnets (DMZ). Separate SG / NACL. JBoss Cluster B — DMZ
Integration Tier SITA/ACCS/GLS adapters, CPA feeds, batch jobs mTLS, API keys, IP allowlists, message-level security Private subnets. NLB or VPC endpoints. No direct internet egress (NAT GW only). JBoss Cluster C — integration
Deployment recommendation: Maintain minimum two separate JBoss EAP 8 clusters (internal + DMZ) — ideally a third for headless integration services. This mirrors the existing WebLogic managed-server split and contains the blast radius. EKS migration is a future phase option for containerised microservices.
Section 03

External & Corporate Integrations

CCT sits at the centre of HKIA's cargo community. Five external/corporate interfaces carry regulatory, operational, and financial messages that must not be disrupted during migration. Each requires advance notice, parallel-run validation, and endpoint re-registration.

SITA
Type B / MQ
↔
CCT JBoss
Integration Tier
↔
ACCS
HK Customs
|
GLS
Logistics
↔
CCT JBoss
↔
HKIA One
AAHK Data
|
Cathay Pacific
CPA Corporate
↔
Aurora PG
SITA

SITA Messaging & Network Services

Protocol: IATA Cargo-IMP message types — FWB (Waybill), FHL (House Manifest), FSU (Status Update), FBL (Loading List). Transport: SITA MQ / Type B network or SITA Air Transport Communications (SITA ATC).

Migration impact: WebLogic Foreign JMS connection factories referencing SITA MQ must be recreated in JBoss as remote ActiveMQ Artemis/IBM MQ bridges. AWS NAT Gateway egress IPs must be submitted to SITA for allowlisting. Direct Connect path preferred for latency SLA. MDB retry logic and DLQ handling must be validated on Artemis.

ACCS

Air Cargo Clearance System (HK Customs)

Operator: Hong Kong Customs & Excise Department. Purpose: Electronic cargo manifest submission, import/export clearance declarations, truck gate pass validation, and hold/release notifications for controlled cargo.

Migration impact: Certificate-based client authentication must be re-issued for AWS endpoints. ACCS vendor must register new CCT callback URLs. Trucker mobile gate-pass flow is a primary ACCS consumer — validate with full trucker app integration test in ACCS sandbox.

GLS

Global Logistics System

Purpose: Shipment tracking, status event exchange, inter-terminal manifest, and logistics partner EDI. May use SFTP file drops, AS2, or REST API depending on implementation version.

Migration impact: SFTP drop zones move from on-prem NAS to S3 with SFTP endpoint (AWS Transfer Family) or S3 event-triggered Lambda replacing file watchers. AS2 partners require new EDI partner configuration pointing to AWS endpoints. Validate GLS handshake certificates.

HKIA One Data Platform

Airport Authority HK — Unified Data Hub

Purpose: Operational and analytics data sharing across HKIA stakeholders — flight schedules, cargo volumes, gate utilisation, truck queuing analytics.

Migration impact: Re-establish data pipeline from AWS. AAHK governance review required for cloud-hosted data sources. Confirm whether connector is API-pull, event push (Kafka/MQ), or SFTP. Data residency must remain ap-east-1 per AAHK governance policy.

Cathay Pacific Airways

Parent Company — Corporate Data Interfaces

Interfaces include: Flight schedule feeds · Cargo capacity allocations · Revenue accounting reconciliation · HR/Identity (Entra ID federation from CPA tenant) · Operational KPI reporting · Shared Master Data (customer, agent, commodity codes).

Implementation types: Oracle DB Links (to be replaced), REST APIs, ESB messaging (CPA MuleSoft), ETL batch files.

Migration impact: Oracle DB Links from CCT Oracle to CPA Oracle schemas — replace with REST API or AWS PrivateLink endpoint into CPA network. Entra ID app registrations: new JBoss callback URLs on AWS must be registered in the shared CPA Entra tenant. SAML metadata must be updated. Coordinate with CPA IAM team (6–8 weeks lead time).

Integration migration approach

IntegrationCurrent transportAWS targetPartner notice neededCutover complexity
SITA WebLogic JMS → SITA MQ Amazon MQ (ActiveMQ) → SITA MQ bridge over Direct Connect ● Yes — IP allowlisting, endpoint change ▲ Medium
ACCS HTTPS REST + client cert, on-prem IPs AWS NAT/EIP registered with ACCS. New client cert issued for AWS. ● Yes — cert + IP re-registration ▲ Medium
GLS SFTP drop / AS2 / REST AWS Transfer Family SFTP or S3 event-driven + Lambda ● Yes — partner EDI config change ■ Low–Medium
HKIA One API / file push from on-prem API from AWS (or Kafka bridge) ● Yes — AAHK approval for cloud source ■ Low
CPA Corporate Oracle DB links + MuleSoft ESB + REST REST APIs or PrivateLink into CPA network + Entra ID federation update ● Yes — IAM team + DB link decommission ▲ High
Integration cutover risk: External partners require advance notice (typically 4–12 weeks) and sandbox/parallel-run periods. Do not migrate all interfaces in a single big-bang cutover. Maintain on-prem integration endpoints as fallback for the full hypercare period per partner.
Section 04

WebLogic 12.x → JBoss EAP 8 Migration

JBoss EAP 8 is Red Hat's enterprise distribution of WildFly, targeting Jakarta EE 10 (Java 17/21). Migration from WebLogic requires application assessment, descriptor replacement, security model re-architecture, and JMS re-plumbing.

Key differences — WebLogic vs JBoss EAP 8

AreaWebLogic 12.xJBoss EAP 8Migration action
Deployment descriptors weblogic.xml, weblogic-application.xml, weblogic-ejb-jar.xml jboss-web.xml, jboss-app.xml, jboss-ejb3.xml, jboss-deployment-structure.xml Remove all WL descriptors; add JBoss equivalents or use portable Jakarta EE descriptors only
DataSource / JDBC JDBC stores configured in config.xml / admin console datasources subsystem in standalone.xml or domain.xml; managed via CLI Export WL datasources; recreate in JBoss CLI with PG JDBC driver. Update JNDI to java:jboss/datasources/
JMS WebLogic JMS Server, SAF agents, foreign JMS (IBM MQ) ActiveMQ Artemis (embedded or Amazon MQ remote broker) Remap queues/topics. Update @MessageDriven activation config. Validate DLQ and poison message handling on Artemis.
Security / AuthN DefaultAuthenticator, LDAP authenticator, embedded LDAP Elytron subsystem — SAML, OIDC, LDAP, file-backed realms Configure Elytron OIDC client for Entra ID (internal). Configure standalone HTTP security realm for external apps. Separate security-domain per cluster.
Clustering / HA Multicast / unicast cluster, replicated HTTP sessions Infinispan distributed cache, mod_cluster / AWS ALB sticky sessions Prefer stateless APIs + JWT for external-facing apps. Use Infinispan replication only for stateful internal web sessions.
Classloading prefer-application-packages in weblogic.xml jboss-deployment-structure.xml module exclusions/inclusions Resolve library conflicts (Hibernate, Jackson, Log4j). Use deployment-structure.xml to isolate shared library versions.
Java version Java 8 / 11 (typical WL 12.1.x–12.2.x) Java 17 (required) / Java 21 (supported) Mandatory javax → jakarta namespace migration (EE 10). Scan with MTA/Windup. Update all maven/gradle dependencies.
Thread pools / Work managers WebLogic Work Managers with constraints JBoss thread pool executor subsystem (io subsystem) Map WL Work Manager thread constraints to EAP executor pool settings in standalone.xml
EJB Timers WebLogic Timer Service (in-memory or persistent) Jakarta EE Timer Service or MicroProfile Metrics-aware Quartz Validate timer persistence. If cluster-wide timers are needed, use Jakarta EE persistent timer with Aurora PG as timer store.

Application migration steps

Step 01 — Discovery

Inventory all artefacts

  • List all EAR/WAR deployments and shared libraries in WebLogic domain
  • Export JNDI tree — datasources, JMS destinations, EJB references
  • Identify WebLogic-specific API imports (weblogic.* packages)
  • Document EJB timers, MDB activation specs, and Work Manager configurations
Step 02 — Assessment

MTA / Windup scan

  • Run Red Hat Migration Toolkit for Applications (MTA 6.x) against each EAR/WAR
  • Flag javax → jakarta, deprecated EJB 2.x, proprietary WebLogic APIs
  • Generate story-point effort estimates per module
  • Identify Oracle JDBC proprietary calls (OracleDataSource, OracleTypes)
Step 03 — Refactor

Code & config updates

  • javax.* → jakarta.* namespace bulk refactor
  • Replace weblogic.xml with jboss-web.xml / jboss-deployment-structure.xml
  • Update persistence.xml: Hibernate dialect to PostgreSQLDialect
  • Replace WebLogic JMS with ActiveMQ Artemis @MessageDriven activation config
  • Externalise config to MicroProfile Config / environment variables
Step 04 — Deploy & Validate

JBoss EAP 8 on AWS dev

  • Deploy each EAR/WAR; fix deployment exceptions
  • Functional smoke test per channel (internal, agents, trucker, airline)
  • Compare response time & memory vs WebLogic baseline
  • End-to-end Entra ID OIDC login flow validation

JBoss EAP 8 — Key configuration examples

XML — JBoss EAP 8 CLI / standalone.xml standalone.xml — datasources subsystem 
<!-- Aurora PostgreSQL Datasource — Internal Applications -->
<datasource jndi-name="java:jboss/datasources/CCTDS"
            pool-name="CCT_AURORA_PG"
            enabled="true"
            use-java-context="true">
  <connection-url>jdbc:postgresql://${CCT_DB_HOST}:5432/cctdb</connection-url>
  <driver>postgresql</driver>
  <security>
    <user-name>${CCT_DB_USER}</user-name>
    <password>${CCT_DB_PASS}</password> <!-- injected from AWS Secrets Manager -->
  </security>
  <pool>
    <min-pool-size>10</min-pool-size>
    <max-pool-size>50</max-pool-size>
    <prefill>true</prefill>
  </pool>
  <validation>
    <check-valid-connection-sql>SELECT 1</check-valid-connection-sql>
    <validate-on-match>true</validate-on-match>
    <background-validation>true</background-validation>
  </validation>
</datasource>
XML — JBoss EAP 8 Elytron OIDC standalone.xml — Azure Entra ID OIDC for internal web apps 
<subsystem xmlns="urn:wildfly:elytron-oidc-client:2.0">
  <provider name="azure-entra">
    <provider-url>https://login.microsoftonline.com/${ENTRA_TENANT_ID}/v2.0</provider-url>
    <ssl-required>external</ssl-required>
  </provider>
  <secure-deployment name="cct-internal-web.war">
    <provider>azure-entra</provider>
    <client-id>${ENTRA_CLIENT_ID}</client-id>
    <credentials>
      <secret>${ENTRA_CLIENT_SECRET}</secret> <!-- from Secrets Manager -->
    </credentials>
    <redirect-rewrite-rule pattern="^/cct-internal-web(.*)" replacement="$1"/>
    <ssl-required>external</ssl-required>
    <principal-attribute>preferred_username</principal-attribute>
  </secure-deployment>
</subsystem>

<!-- Map Entra Group IDs to JBoss application roles in jboss-web.xml -->
<jboss-web>
  <security-domain>entra-oidc</security-domain>
  <valve>
    <class-name>org.jboss.security.authorization.DelegatingAuthorizationModule</class-name>
  </valve>
</jboss-web>
Java — Message-Driven Bean (EE 10) SitaFwbMessageProcessor.java — updated for ActiveMQ Artemis 
@MessageDriven(activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationType",   propertyValue = "jakarta.jms.Queue"),
    @ActivationConfigProperty(propertyName = "destination",        propertyValue = "java:/jms/queue/sita.inbound.fwb"),
    @ActivationConfigProperty(propertyName = "acknowledgeMode",    propertyValue = "Auto-acknowledge"),
    @ActivationConfigProperty(propertyName = "maxSession",         propertyValue = "10"),
    @ActivationConfigProperty(propertyName = "rebalanceConnections",propertyValue = "true") // Artemis-specific
})
public class SitaFwbMessageProcessor implements MessageListener {
    @Inject private CargoWaybillService waybillService;

    @Override
    public void onMessage(Message message) {
        try {
            TextMessage tm = (TextMessage) message;
            // Parse IATA FWB cargo-IMP message
            waybillService.processFwb(tm.getText());
        } catch (JMSException e) {
            // Artemis DLQ: automatic after maxDeliveryAttempts exceeded
            throw new RuntimeException("FWB processing failed — routed to DLQ", e);
        }
    }
}

Azure Entra ID integration checklist

Internal user authentication flow on JBoss EAP 8
1. Staff → CCT Internal Web / Mobile App 2. JBoss Elytron OIDC redirect → Entra ID 3. User authenticates (Conditional Access + MFA) 4. ID Token + Access Token returned to JBoss 5. Entra groups → JBoss roles via oidc-role-mapper 6. JWT forwarded to downstream API / DB
Entra ID action checklist:
Section 05

Oracle → Aurora PostgreSQL Migration

Database replatforming is the highest-risk axis. CCT cargo systems rely heavily on PL/SQL stored procedures for cargo validation, customs calculations, and ACCS integration logic. This section covers schema conversion, data migration tooling, stored procedure rewrite, and cutover strategy.

Data type mapping — Oracle → PostgreSQL

Oracle typePostgreSQL equivalentNotes & pitfalls
VARCHAR2 / NVARCHAR2VARCHAR / TEXTOracle empty string ≡ NULL — PostgreSQL distinguishes them. Audit application null-checks.
NUMBERNUMERIC(p,s) / INTEGER / BIGINTNUMBER without precision → NUMERIC. Use INTEGER for pk/fk integers for performance.
DATE (includes time component)TIMESTAMPOracle DATE stores time; PostgreSQL DATE is date-only. All Oracle DATE columns → TIMESTAMP.
TIMESTAMP WITH TIME ZONETIMESTAMPTZDirect equivalent. Confirm timezone handling in cargo event timestamps.
CLOB / NCLOBTEXTMax size unlimited in PG. Remove DBMS_LOB calls; use standard string functions.
BLOBBYTEAChange JDBC calls from OracleBLOB to setBytes/getBytes. Review binary doc storage pattern.
ROWID / ROWNUMctid (internal) / ROW_NUMBER()Replace ROWNUM pagination with LIMIT/OFFSET. Remove direct ROWID references.
DUAL (pseudo-table)Omit — SELECT without FROMSELECT SYSDATE FROM DUAL → SELECT NOW(). Remove all references to DUAL.
SEQUENCE.NEXTVALNEXTVAL('seq_name')Re-create Oracle sequences as PG sequences. Use IDENTITY columns for new tables.
SYSDATE / SYSTIMESTAMPNOW() / CURRENT_TIMESTAMPDirect replacement. Watch format differences in string concatenation.
NVL(a, b)COALESCE(a, b)Direct SQL equivalent.
DECODECASE WHEN … ENDAWS SCT converts automatically. Verify complex DECODE nesting.

PL/SQL → plpgsql conversion examples

PL/SQL — Oracle (Before) pkg_cargo_validation.sql — cargo weight validation procedure 
-- Oracle PL/SQL stored procedure
CREATE OR REPLACE PROCEDURE validate_cargo_weight(
    p_awb_number   IN  VARCHAR2,
    p_gross_weight IN  NUMBER,
    p_result       OUT VARCHAR2
) AS
    v_limit NUMBER;
    v_commodity VARCHAR2(10);
BEGIN
    SELECT weight_limit, commodity_code
    INTO   v_limit, v_commodity
    FROM   cargo_awb
    WHERE  awb_number = p_awb_number
    AND    ROWNUM = 1;  -- Oracle-specific!

    IF p_gross_weight > v_limit THEN
        p_result := 'OVERWEIGHT:' || TO_CHAR(v_limit);
    ELSE
        p_result := 'OK';
    END IF;
EXCEPTION
    WHEN NO_DATA_FOUND THEN
        p_result := 'AWB_NOT_FOUND';
END;
plpgsql — PostgreSQL (After) fn_validate_cargo_weight.sql — converted for Aurora PostgreSQL 
-- PostgreSQL plpgsql function (procedures return void; use functions for output)
CREATE OR REPLACE FUNCTION validate_cargo_weight(
    p_awb_number   VARCHAR,
    p_gross_weight NUMERIC
) RETURNS VARCHAR AS $$
DECLARE
    v_limit    NUMERIC;
    v_commodity VARCHAR(10);
BEGIN
    SELECT weight_limit, commodity_code
    INTO   v_limit, v_commodity
    FROM   cargo_awb
    WHERE  awb_number = p_awb_number
    LIMIT 1;  -- replaces ROWNUM = 1

    IF NOT FOUND THEN
        RETURN 'AWB_NOT_FOUND';
    END IF;

    IF p_gross_weight > v_limit THEN
        RETURN 'OVERWEIGHT:' || v_limit::TEXT;
    ELSE
        RETURN 'OK';
    END IF;
END;
$$ LANGUAGE plpgsql;

Migration tooling

AWS SCT

Schema Conversion Tool

AWS SCT (Schema Conversion Tool) automatically converts Oracle DDL (tables, views, indexes, sequences) to PostgreSQL equivalents and generates an assessment report flagging manual conversion items — especially PL/SQL stored procedures. Target: Oracle → Aurora PostgreSQL conversion report before starting.

AWS DMS

Database Migration Service (CDC)

AWS DMS with Oracle LogMiner as source for Change Data Capture (CDC). Enables continuous replication from on-prem Oracle to Aurora PostgreSQL during migration period. Zero-downtime approach — both DBs stay in sync. Recommended cutover: stop writes → final flush → switch JDBC connection string.

Recommended

Parallel-run reconciliation

JBoss apps on AWS write to Aurora PostgreSQL. DMS continues to sync back for 2–4 week parallel run. Run nightly reconciliation SQL comparing critical cargo tables (AWBs, manifests, gate records). 100% match required before decommissioning Oracle.

Alternative

Big-bang maintenance window

Stop writes to Oracle, allow final DMS flush, switch JBoss datasource JNDI to Aurora, restart JBoss, resume. Requires extended maintenance window (4–6 hour minimum given CCT data volumes). Higher risk — only viable if cargo volumes permit a weekend window.

Oracle-specific CCT risks:
Section 06

On-premises → AWS Cloud Architecture

Target landing zone in AWS Asia Pacific (Hong Kong) — ap-east-1. All CCT data remains in Hong Kong for PDPO and HKIA governance compliance. Two-AZ deployment minimum for HA; Aurora Global Database deferred until data residency review.

Target AWS architecture — layered

Users & clients
CCT staff (Entra ID — CPA VPN) Freight agents & freighters (Internet) Truckers (mobile — Internet) Airline users (federated SSO) Cathay Pacific corporate network SITA / ACCS / GLS / HKIA One systems
↓
Edge & security (Internet-facing only)
Route 53 (DNS + health checks) CloudFront (static assets, mobile CDN) AWS WAF (OWASP Core Rule Set + custom CCT rules) AWS Shield Standard ACM (TLS 1.3 certificates)
↓
Load balancing — two separate ALBs
ALB-A — Internal (private subnets) → JBoss Cluster A ALB-B — DMZ (public subnets + WAF) → JBoss Cluster B NLB — Integration services (static IP for ACCS/GLS partner allowlisting)
↓
Compute — JBoss EAP 8 clusters (EC2 Auto Scaling)
Cluster A — Internal web + mobile API (m6i.xlarge × 2+ AZ) Cluster B — DMZ: Agents + Trucker API + Airline portal (m6i.xlarge × 2+ AZ) Cluster C — Integration + batch services (m6i.large × 2, no ALB)
↓
Data & messaging
Aurora PostgreSQL — Multi-AZ writer + 1 read replica ElastiCache Redis — JBoss HTTP session cache (internal) Amazon MQ (ActiveMQ) — SITA message bridge S3 — cargo docs, audit logs, GLS file drops AWS Transfer Family — SFTP endpoint (GLS/EDI partners) Secrets Manager — DB credentials, Entra client secrets, API keys KMS — encryption keys (at-rest: Aurora, S3, EBS)
↓
Connectivity & observability
AWS Direct Connect (1 Gbps) — CPA HQ + HKIA datacentre Transit Gateway — multi-VPC routing Site-to-Site VPN (backup to Direct Connect) CloudWatch Logs + Metrics + Alarms AWS X-Ray — distributed tracing CloudTrail — API audit log GuardDuty + Security Hub

On-prem to AWS service mapping

On-prem
Hardware LB (F5 / Citrix NetScaler)
SSL termination, VIP routing to WebLogic cluster
→
AWS
Application Load Balancer (ALB) × 2
Path-based routing. ACM TLS termination. Separate ALBs for internal vs DMZ. WAF attached to DMZ ALB.
On-prem
VMware vSphere / bare-metal servers
WebLogic managed servers; 4–8 vCPU, 16–32 GB RAM/node
→
AWS
EC2 m6i.xlarge / m6i.2xlarge (Auto Scaling)
ASG across 2 AZs. Golden AMI: RHEL 9 + JBoss EAP 8 + CloudWatch agent. Launch template with user data secrets injection.
On-prem
Oracle RAC / single-node + Data Guard
SAN iSCSI/FC storage. RMAN backup. Standby DR node.
→
AWS
Amazon Aurora PostgreSQL (Multi-AZ)
Auto-failover <30s. Automated backups 35-day retention. PITR. Performance Insights. Zero-downtime minor patching.
On-prem
IBM MQ / WebLogic JMS Server
SITA message queues, internal async processing, SAF agents
→
AWS
Amazon MQ (ActiveMQ 5.x) + Artemis (embedded JBoss)
Amazon MQ for SITA bridge (managed broker). Artemis embedded in JBoss for internal async. JMS bridge between the two.
On-prem
On-prem NAS / SFTP servers
GLS file drops, report exports, EDI partner exchanges
→
AWS
S3 + AWS Transfer Family (SFTP)
S3 event → Lambda triggers replace on-prem file watchers. Transfer Family provides partner-compatible SFTP endpoint.
On-prem
AD FS / on-prem LDAP
Windows Integrated Auth (Kerberos/NTLM) for CCT staff
→
AWS
Azure Entra ID (OIDC / SAML 2.0)
Cloud-native IdP. Conditional Access. MFA. Integrated with CPA corporate Entra tenant. JBoss Elytron OIDC subsystem.
Section 07

Security & Compliance

CCT processes regulated cargo data under HKIA operator agreements, Hong Kong PDPO, and aviation authority requirements. All data must remain in ap-east-1. External-facing applications are exposed to the public internet and require defence-in-depth.

Compliance

Hong Kong PDPO

Personal Data (Privacy) Ordinance — passenger data, agent contact data. Data must not leave HK region. All Aurora data encrypted at rest (KMS). TLS 1.3 in transit. No cross-region replication without legal review.

Compliance

Aviation Security (AvSec)

HKIA cargo security requirements under Civil Aviation Dept. Access to cargo manifest and security status data restricted. RBAC enforced at application + database level. Audit trail for all cargo status changes.

Compliance

HK Customs — ACCS

Cargo clearance data handled under HK Customs mandate. Only authorised CCT terminals and approved integrators may submit. mTLS certificate-based auth for ACCS connectivity from AWS.

Security architecture layers

LayerControlImplementation
Edge — Internet-facing WAF, DDoS protection, geo-restriction AWS WAF with OWASP CRS + custom rules (bot control, rate limiting per IP). AWS Shield Standard. CloudFront geo-block non-HK/CN agents if required.
Identity — Internal users MFA, Conditional Access, RBAC Azure Entra ID. MFA required for all CCT app logins. Conditional Access: block access from non-corporate devices. Entra groups → JBoss roles.
Identity — External users Self-service registration, email MFA, API keys JBoss custom security realm. Rate-limit registration API (WAF rule). API keys for trucker and airline system integrations.
Network — VPC Segmentation, least privilege 3-tier VPC: public (ALB/NLB), private (JBoss EC2), data (Aurora, ElastiCache). NACLs restrict lateral movement. Security Groups: JBoss SG only accepts traffic from ALB SG.
Data at rest Encryption, key management Aurora: KMS CMK encryption. S3 buckets: SSE-KMS. EBS volumes (JBoss EC2): encrypted. KMS key rotation: annual. Secrets Manager for credentials rotation.
Data in transit TLS everywhere TLS 1.3 on ALB. Internal JBoss ↔ Aurora: SSL mode=verify-full. Amazon MQ: TLS-only. Direct Connect: MACsec Layer 2 encryption (if required by CPA).
Audit & monitoring Immutable audit trail CloudTrail (all API calls). Aurora PostgreSQL pg_audit extension (row-level). CloudWatch Logs retention: 1 year. S3 Glacier archive: 7 years.
Vulnerability management Continuous scanning Amazon Inspector (EC2 + ECR container scanning). GuardDuty (threat detection). Security Hub (FSBP compliance score). Penetration test: pre-go-live on DMZ cluster.

Secret management — AWS Secrets Manager

Shell — AWS CLI secrets provisioning (pre-deployment) 
# Store Aurora PG credentials
aws secretsmanager create-secret \
  --name "cct/prod/db/aurora-pg" \
  --description "CCT Aurora PostgreSQL credentials" \
  --secret-string '{"username":"cct_app","password":"<GENERATED>"}' \
  --kms-key-id "arn:aws:kms:ap-east-1:ACCOUNT:key/CCT-CMK"

# Store Entra ID OIDC client secret
aws secretsmanager create-secret \
  --name "cct/prod/entra/client-secret-internal" \
  --secret-string '{"clientId":"<APP_ID>","clientSecret":"<SECRET>"}'

# Rotate automatically every 90 days
aws secretsmanager rotate-secret \
  --secret-id "cct/prod/db/aurora-pg" \
  --rotation-lambda-arn "arn:aws:lambda:ap-east-1:ACCOUNT:function:cct-secret-rotator" \
  --rotation-rules '{"AutomaticallyAfterDays":90}'

# JBoss startup: inject secrets via environment variable from ASG user data
export CCT_DB_PASS=$(aws secretsmanager get-secret-value \
  --secret-id "cct/prod/db/aurora-pg" \
  --query 'SecretString' --output text | jq -r '.password')
Data residency enforcement: Apply a Service Control Policy (SCP) at the AWS Organization level to deny all API calls that write data outside ap-east-1 (e.g. aws:RequestedRegion != ap-east-1). This prevents accidental cross-region data writes from any account in the CCT AWS Organisation.
Section 08

CI/CD Pipeline & DevOps

Moving to AWS enables a modern GitOps-driven deployment pipeline. Infrastructure is defined as code (Terraform), application builds are automated (Jenkins/GitHub Actions), and JBoss deployments are blue/green with automated rollback triggers.

Pipeline architecture

Git push
GitHub / Bitbucket
→
CI Build
Maven/Gradle + Unit tests
→
SAST / DAST
SonarQube + OWASP ZAP
→
Build EAR/WAR
Artifact to S3
→
CodeDeploy
Blue/Green to EC2 ASG
→
Health check
ALB → JBoss /health
→
Prod live
Route 53 swap
IaC

Terraform — Infrastructure as Code

All AWS resources defined in Terraform modules: VPC, subnets, SGs, ALBs, EC2 ASGs, Aurora cluster, Amazon MQ, Secrets Manager, IAM roles. State stored in S3 + DynamoDB lock. Environments (dev/uat/prod) use Terraform workspaces. Module versions pinned — no unplanned drift.

Deploy

Blue/Green Deployment (AWS CodeDeploy)

CodeDeploy with EC2 ASG deployment groups. Blue = current production JBoss cluster. Green = new version cluster. ALB target group swap after JBoss health check passes (/health/ready). Automatic rollback if health checks fail within 5 minutes.

DB

Database Migrations — Flyway

All Aurora PostgreSQL schema changes managed via Flyway version-controlled migration scripts. Migrations run automatically at JBoss startup (dev/uat) or via CI pipeline step (prod) before deployment. Flyway repair command available for failed migration recovery.

Config

MicroProfile Config — Externalised Config

All JBoss application configuration externalised via MicroProfile Config. Sources: environment variables (EC2 launch template) → Secrets Manager → system properties. No hardcoded config in EAR/WAR. Different values per environment with zero code change.

YAML — GitHub Actions workflow .github/workflows/deploy-jboss.yml 
name: CCT JBoss EAP 8 — Build & Deploy

on:
  push:
    branches: [main, release/*]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Java 17
        uses: actions/setup-java@v4
        with: { java-version: '17', distribution: 'temurin' }
      - name: Maven build + unit test
        run: mvn clean package -Dmaven.test.skip=false
      - name: SonarQube SAST scan
        run: mvn sonar:sonar -Dsonar.host.url=$SONAR_URL
      - name: Upload EAR to S3
        run: aws s3 cp target/cct-app.ear s3://cct-artefacts/\$GITHUB_SHA/
      - name: CodeDeploy blue/green deployment
        run: |
          aws deploy create-deployment \
            --application-name cct-jboss-app \
            --deployment-group-name prod-blue-green \
            --s3-location bucket=cct-artefacts,key=\$GITHUB_SHA/cct-app.ear,bundleType=zip
Section 09

Monitoring & Observability

CCT operates 24/7 for cargo handling at HKIA. Zero blind spots are acceptable on production. Three pillars: metrics (CloudWatch), traces (X-Ray), and logs (CloudWatch Logs / OpenSearch). Alerting integrated with CCT operations NOC.

Metrics

CloudWatch Dashboards

Custom CCT dashboard: JBoss JVM heap/GC metrics (CloudWatch agent), ALB request rate + 5xx error rate, Aurora DB CPU/connections/read latency, Amazon MQ queue depth (SITA backlog), EC2 Auto Scaling events, and active user session count per app cluster.

Traces

AWS X-Ray Distributed Tracing

X-Ray SDK instrumented in JBoss apps to trace: inbound ALB requests → JBoss → Aurora DB calls → Amazon MQ messages → external SITA/ACCS calls. Service map shows P95 latency per integration hop. Critical for diagnosing SITA message processing SLA breaches.

Logs

Centralised Log Management

CloudWatch Logs agent on all JBoss EC2 nodes. Log groups per cluster. Metric filters detect ERROR/EXCEPTION patterns. Optional: CloudWatch Logs → Kinesis → Amazon OpenSearch for full-text search over cargo AWB logs and SITA message history.

Critical alarms — CCT cargo operations

AlarmThresholdActionPriority
SITA inbound queue depth > 100 messages for >5 min PagerDuty → CCT integration team on-call ■ P1
ACCS callback timeout rate > 5% errors in 5 min window PagerDuty → operations team + ACCS partner notification ■ P1
ALB 5xx error rate (Agents portal) > 1% for 2 consecutive minutes SNS → Slack #cct-ops + auto-scaling scale-out ▲ P2
Aurora DB CPU > 80% for 10 minutes SNS → DBA team. Consider read replica promotion. ▲ P2
JBoss JVM heap usage > 90% for 5 minutes CloudWatch alarm → ASG scale-out + thread dump capture ▲ P2
Trucker gate API response time P95 > 2 sec for 5 min SNS → operations team. Truck queue SLA at risk. ▲ P2
Aurora failover event RDS event: DB_INSTANCE_FAILOVER PagerDuty P1. Validate JBoss connection pool reconnect. ■ P1
JBoss health check endpoint: Expose GET /health/ready and GET /health/live via MicroProfile Health (jakarta.health). ALB target group health check uses /health/ready. Readiness check validates: DB connection pool, Amazon MQ broker connection, ACCS endpoint reachability. Liveness check validates JVM is responsive.
Section 10

Team Structure & RACI

Migration programme requires a dedicated cross-functional team of 8–12 engineers. Key decisions require active participation from Cathay Pacific IAM team, AAHK HKIA One team, and SITA/ACCS integration vendors.

👷

App Engineers (×2–3)

javax→jakarta, JBoss descriptors, OIDC integration, MDB refactor

🗄️

DBA / Data Engineers (×2)

Oracle→PG schema conversion, PL/SQL rewrite, DMS setup, reconciliation

☁️

AWS Cloud Engineers (×2)

VPC, ALB, EC2 ASG, Aurora, IaC (Terraform), CI/CD pipeline

🔌

Integration Engineers (×1–2)

SITA/ACCS/GLS connectivity, Amazon MQ bridge, partner liaison

🔒

Security Engineer (×1)

WAF rules, KMS, IAM policies, pen test, PDPO compliance

🧪

QA / Test Engineers (×1–2)

SIT, UAT, performance test, reconciliation scripts, regression automation

📋

Programme Manager (×1)

Timeline, steering committee, partner coordination, risk management

🏢

CPA IAM Team (Advisory)

Entra ID federation trust, app registration approvals, Conditional Access policies

RACI matrix (R=Responsible A=Accountable C=Consulted I=Informed)

Activity App Eng DBA Cloud Eng Integration Security QA PM CPA IAM
MTA/Windup app assessmentRCIICCAI
AWS landing zone (VPC/IaC)IIRCAIAI
Oracle schema conversion (SCT)CRCIICAI
JBoss EAP 8 app migrationRCCCCCAI
Entra ID OIDC integrationRICICCAR
SITA/ACCS endpoint migrationCICRCCAI
DMS CDC setup & validationIRCIICAI
UAT & performance testingCCCCCRAI
Production cutover executionRRRRCCAC
Section 11

Migration Phases & Timeline

Phased approach de-risks the three-axis migration. Recommended sequence: AWS foundation first, then database parallel-run, then application server cutover by wave. Total indicative duration: 12–18 months.

Phase 0 — Foundation (8–12 wks)

AWS landing zone & governance

  • AWS Organisation, multi-account (dev/uat/prod)
  • VPC, subnets, SGs, NACLs, IAM, SCPs
  • Direct Connect 1 Gbps to CPA/HKIA DC
  • Terraform IaC for all infrastructure
  • CI/CD pipeline (GitHub Actions + CodeDeploy)
  • Entra ID app registrations for dev/uat URLs
  • CloudWatch dashboards, alarms, GuardDuty
Phase 1 — Assess (6–8 wks)

Discovery & planning

  • MTA/Windup scan all EAR/WAR modules
  • Oracle SCT assessment report
  • Integration dependency mapping (all 5 partners)
  • Non-functional requirements (RTO/RPO, peak TPS)
  • Migration wave plan per application channel
  • DMS CDC proof-of-concept (pilot schema)
  • SITA/ACCS sandbox environment access
Phase 2 — Build (12–16 wks)

Target environment & conversion

  • JBoss EAP 8 on EC2 (dev + UAT clusters)
  • Aurora PostgreSQL — schema conversion & deploy
  • Application refactor: javax→jakarta, PG SQL
  • DMS CDC setup: Oracle (on-prem) → Aurora
  • Entra ID OIDC integration (dev/uat validation)
  • Amazon MQ + SITA bridge (sandbox)
  • Flyway DB migration scripts
Phase 3 — Test (8–10 wks)

SIT, UAT & performance

  • Functional regression per application channel
  • Integration testing: SITA/ACCS/GLS sandboxes
  • Load test — 150% peak cargo handling TPS
  • Security penetration test (DMZ cluster)
  • DR failover test (Aurora Multi-AZ)
  • Trucker gate processing latency validation (<30s)
  • Oracle → PostgreSQL data reconciliation report
Phase 4 — Migration Waves (12–20 wks)

Progressive channel cutover

  • Wave 1: Integration/batch services only (lowest user impact)
  • Wave 2: Airline web portal (controlled airline user base)
  • Wave 3: Agents & Freighters portal + Trucker mobile app
  • Wave 4: Internal web & mobile (Entra ID — CCT staff)
  • Parallel-run + hypercare period per wave (2–4 weeks)
  • Oracle DMS CDC continues throughout all waves
Phase 5 — Decommission (4–6 wks)

On-prem retirement

  • Final Oracle data reconciliation — 100% match confirmed
  • Oracle license termination notice to Oracle
  • WebLogic cluster graceful shutdown
  • On-prem VMware / bare-metal hardware return
  • Archive audit logs to S3 Glacier (7-year retention)
  • Post-implementation review & lessons learned
  • Handover to CCT BAU operations team
Indicative total duration: 12–18 months for a programme of this complexity, assuming a dedicated team of 8–12 engineers (app, DBA, infra, integration, QA, security) and active engagement from Cathay Pacific IAM team, SITA, ACCS/HK Customs, and AAHK HKIA One teams. Gateway reviews at end of each phase recommended before proceeding.
Section 12

Cutover, Risks & Testing Checklist

CCT cargo terminal systems operate 24/7. Cutover planning must account for peak import/export windows, HKIA flight schedules, regulatory reporting deadlines, and ACCS gate operation hours.

Top risks & mitigations

RiskImpactLikelihoodMitigation
PL/SQL conversion gaps Data corruption, incorrect cargo calculations ▲ Medium Parallel-run with automated reconciliation. Dedicated DBA review of all stored procedures. Full regression before cutover.
SITA/ACCS connectivity break Customs clearance delays, flight disruptions ▲ Medium Pre-register AWS NAT EIPs. Keep on-prem fallback endpoints live. Partner-approved cutover windows. SITA sandbox validation mandatory.
Entra ID SSO misconfiguration CCT internal staff locked out of terminal systems ▲ Medium Pilot group of 20 users before full rollout. Keep break-glass local JBoss admin accounts. CPA IAM team on standby during cutover.
PostgreSQL performance regression Slow gate processing, trucker queue backlog, SLA breach ▲ Medium Load test at 150% peak TPS. Tune indexes, query plans, vacuum settings. Aurora read replicas for reporting queries.
javax → jakarta breaking changes Application deployment failures on JBoss EAP 8 ● High MTA/Windup scan early in Phase 1. Full library upgrade in Phase 2. Consider JBoss EAP 7 (EE 8) as intermediate step if javax migration proves complex.
Oracle DB Links to CPA schemas CPA data feeds broken on cutover ▲ Medium Replace DB Links with REST API or PrivateLink to CPA network in Phase 2. Validate all CPA interfaces in UAT before Wave 4.
Data residency / compliance breach PDPO regulatory non-compliance ✕ Low SCP denies writes outside ap-east-1. KMS CMK encryption. Legal review before any cross-border data sharing. No Aurora Global Database without approval.
HKIA One data platform disruption AAHK operational reporting gaps ✕ Low AAHK early notification (12+ weeks). Maintain on-prem feed as fallback. Validate new AWS-hosted feed in AAHK UAT environment.

Rollback runbook (per wave)

Markdown — Runbook CCT_ROLLBACK_RUNBOOK.md — decision tree 
# CCT Wave Rollback — Decision Tree

TRIGGER: Any of the following within hypercare window (72h):
  - ALB 5xx rate > 2% sustained 10 minutes
  - SITA message processing backlog > 500 messages
  - Aurora failover + JBoss connection pool not recovering
  - ACCS gate validation failure rate > 5%
  - Business sign-off withdrawal

ROLLBACK STEPS (target: <30 min execution):

1. PM decision: confirm rollback with CCT IT Director
2. DNS: Route 53 CNAME update → point cct-*.cathay-cargo.com back to on-prem F5 LB
   - TTL: 60s (pre-set before cutover)
   - Time: ~2 min
3. DMS: Pause DMS CDC task (stop replication to Aurora)
4. Oracle: Verify on-prem Oracle primary is healthy and accepting writes
5. JBoss on-prem: Confirm WebLogic managed servers are still running (do NOT shut down during hypercare)
6. Integration: Validate SITA/ACCS on-prem endpoints responding
7. Notify: CPA IAM, SITA, ACCS, AAHK teams of rollback
8. Post-rollback: Root cause analysis within 48h. Re-entry plan required before next cutover attempt.

Pre-cutover testing checklist

Design rationale — frequently asked questions

Why migrate from WebLogic to JBoss EAP 8?
WebLogic licensing is Oracle CPU-based and expensive for cloud deployments. JBoss EAP 8 is Red Hat supported, Jakarta EE 10 compliant, Java 17/21 native, and carries no per-CPU licensing cost on AWS EC2. It also aligns CCT with an open-source, vendor-neutral Java EE stack for long-term flexibility.
Why Aurora PostgreSQL over Oracle on AWS?
Oracle CPU-based licensing on AWS adds $30K–$100K+/year per instance. Aurora PostgreSQL is fully managed, Multi-AZ out of the box, integrates natively with DMS for live migration, and has a rich open-source ecosystem. Long-term TCO reduction is estimated at 40%+ on the database layer alone.
How do you migrate with zero downtime for a 24/7 cargo terminal?
DMS Change Data Capture (CDC) keeps Oracle and Aurora PostgreSQL in continuous sync during migration. Each application wave runs in parallel-run mode. Route 53 DNS cutover is scripted and rehearsed. Rollback (DNS revert to on-prem WebLogic) is executable in under 30 minutes. Integration partners are notified and have fallback paths.
How does Azure Entra ID work with applications hosted on AWS?
Entra ID is cloud-agnostic as an OIDC/SAML identity provider. JBoss Elytron OIDC subsystem authenticates users against Entra ID regardless of where JBoss is hosted. Redirect URIs simply point to AWS ALB hostnames. The Entra ID token endpoint is on Microsoft's global infrastructure — no AWS-specific configuration needed on the IdP side.
What is the single hardest part of this migration?
PL/SQL stored procedure rewrite combined with maintaining SITA and ACCS message SLAs during cutover. The application server migration (WebLogic → JBoss) is well-understood with MTA/Windup tooling. Database conversion and external aviation partner integration cutover require the most planning, partner coordination, and parallel-run validation in a live cargo terminal environment.
How is Hong Kong data residency enforced on AWS?
AWS Service Control Policy (SCP) at the Organisation level denies writes to any AWS service outside ap-east-1. All Aurora data encrypted with a KMS Customer Managed Key (CMK) scoped to ap-east-1. S3 bucket policies block cross-region replication. Legal review required before any cross-border data movement.