5.4: Formal End-of-Life (EOL) Plan and Schedule

The final critical phase following the successful migration of data, services, applications and user workflows to the new eMap platform will be the formal End-of-Life (EOL) and decommissioning of the legacy eMap system.

5.4.1 Objectives of the EOL Plan¶

The primary objectives for the formal EOL and decommissioning of the legacy eMap system are:

• Seamless Transition: Ensure no disruption to ongoing business operations or user access to critical GIS functionalities.
• Secure Data Management: Securely archive all necessary data from the legacy system in accordance with Departmental retention policies and regulatory requirements.
• Complete System Retirement: Methodically shut down and remove all components of the legacy eMap system, including application servers, database servers and associated network infrastructure.
• Resource Reclamation: Reclaim all underlying resources, such as virtual machines, storage capacity and software licences associated with the legacy system to optimise costs and resource allocation.
• Clear Stakeholder Communication: Maintain clear and consistent communication with all stakeholders regarding the EOL timeline, process and any final user actions required.
• Knowledge Preservation: Ensure that any critical historical information or documentation related to the legacy system is appropriately archived.

5.4.2 Prerequisites for Initiating EOL¶

Before commencing the formal EOL process for the legacy eMap system, the following criteria should be met:

1. Successful Migration Completion: All critical data, services, applications and user workflows identified in the migration plan must have been successfully migrated to the new eMap platform, with their functionality validated.
2. New Platform Stability and Performance: The new eMap platform must demonstrate stable and satisfactory performance under production load for a defined period post migration of all critical functionalities.
3. User Acceptance and Proficiency: Business owners and key user groups must accept the new eMap platform. Users must have received adequate training and demonstrate proficiency in using the new system for their critical workflows.
4. Parallel Run Conclusion (if applicable): If a period of parallel operation between the legacy and new systems was implemented, this period must have concluded successfully, with the new eMap platform proven to be the reliable system of record.
5. Dependency Resolution: All critical dependencies on the legacy eMap system from other systems or processes must have been successfully redirected to the new eMap platform or decommissioned.
6. EOL Plan Approval: The formal EOL plan and schedule must be approved by relevant stakeholders including Data Owners and Executives.

5.4.3. EOL Process and Schedule¶

The decommissioning of the legacy eMap system shall be executed in a phased manner to ensure a controlled and auditable process. The following diagram illustrates the high level EOL process:

flowchart TB
    subgraph LegacyEOL["Legacy eMap EOL"]
        direction TB
        A[Prerequisites Met<br><small>Migrations Complete, New Platform Validated</small>] --> B["📝 Formal EOL Plan Approved<br>& Schedule Communicated"]
        B --> C["🔒 Legacy System: Read-Only Mode (Optional)<br><small>Final user verification period</small>"]
        C --> D["🔌 System Shutdown & Network Isolation<br><small>Disable access, isolate servers</small>"]
        D --> E["💾 Final Data Archival & Validation<br><small>Secure backups as per retention policies</small>"]
        E --> F["⚙️ Infrastructure Decommissioning<br><small>De-provision VMs, storage, network components</small>"]
        F --> G["📜 Licence Reclamation & Documentation<br><small>Retire licences, archive system docs</small>"]
        G --> H["✅ Post-Decommissioning Validation<br><small>Confirm removal, no impact on new platform</small>"]
    end

    classDef default fill:#fff,stroke:#333,stroke-width:1px;
    classDef prerequisite fill:#e6ffe6,stroke:#008000,stroke-width:2px;
    classDef planning fill:#e3f2fd,stroke:#0d47a1,stroke-width:2px;
    classDef action fill:#fff9c4,stroke:#f57f17,stroke-width:2px;
    classDef final_step fill:#fce4ec,stroke:#c2185b,stroke-width:2px;

    class A prerequisite;
    class B planning;
    class C,D,E,F,G action;
    class H final_step;

5.4.3.1 Phase 1: Pre-EOL Communication and Final Preparations¶

• Official EOL Announcement: Officially announce the definitive EOL date and time for the legacy eMap system to all users and stakeholders.
• Final Transition Timeline Communication: Communicate the detailed shutdown process, including any interim steps such as read-only periods and the support arrangements for the new eMap platform. Reinforce where users can find training, documentation and support for the new platform.
• Final Data Reconciliation: Conduct a final data reconciliation exercise to ensure no critical data has been missed during the migration. Address any discrepancies found.
• User Access Review: Review and confirm the list of users who still have active access to the legacy system. Prepare for access revocation.
• Backup Legacy System Configurations: Take final backups of critical configuration files, system settings and any unique customisations of the legacy eMap system for historical reference.

5.4.3.2 Phase 2: Legacy System Shutdown and Isolation¶

• Legacy System Read-Only Mode (Optional):
  • Transition the legacy eMap system to a read-only state for a brief period (e.g., 2-5 business days) before full shutdown.
  • Communicate this state clearly to all users, indicating that no further data modifications will be possible on the legacy system.
  • This allows a final opportunity for users to retrieve any non-migrated working data and perform final comparisons if necessary.
• User Access Cutoff (T-Day): At the scheduled EOL date and time, disable all user access to the legacy eMap system. This includes disabling login interfaces and application access points.
• System Shutdown (T-Day):
  • Perform a graceful shutdown of all legacy eMap application services (e.g., ArcGIS Server services, Portal services on legacy infrastructure).
  • Shut down the legacy database servers hosting eMap data.
  • Power down all virtual machines dedicated to the legacy eMap system.
• Network Isolation (T-Day to T+2 Days): Isolate the shutdown legacy servers from the network by disabling their network interfaces or reconfiguring firewall rules to block all traffic to and from these systems. This prevents accidental reactivation or unauthorised access.

5.4.3.3 Phase 3: Final Data Archival and Validation¶

• Final Backups: Perform comprehensive, final backups of all legacy eMap databases and file system data from the shutdown servers.
• Secure Archival: Store these final backups securely in a designated archive location (e.g., Azure Blob Storage Archive tier) in accordance with Departmental data retention policies and any applicable legal or regulatory requirements.
• Archive Validation: Verify the integrity and restorability of the archived backups. This may involve a test restore of a sample of the archived data to an isolated environment.
• Documentation: Document the archival process, including backup contents, storage locations and access procedures for the archives.

5.4.3.4 Phase 4: Infrastructure Decommissioning and Resource Reclamation¶

• De-provision Virtual Machines: Delete the legacy eMap VMs from Azure.
• Storage Reclamation: Securely wipe and de-provision storage arrays or disks associated with the legacy VMs and databases.
• Network Configuration Cleanup: Remove DNS records, firewall rules, load balancer configurations and any other network settings that refer to the legacy eMap system.
• Software Licence Reclamation: Identify and reclaim any software licences associated with the legacy eMap system.

5.4.3.5 Phase 5: Post-Decommissioning Validation and Closure¶

• Verification of Decommissioning: Conduct a final audit to confirm that all legacy eMap system components have been successfully decommissioned and no remnants remain in the production environment.
• Impact Assessment Review: Monitor the new eMap platform and related systems for any unexpected issues or dependencies that may have been missed.
• Lessons Learned: Conduct a post decommissioning review or lessons learned session with the project team and key stakeholders to capture insights and improve processes for future initiatives.
• Formal Closure: Formally close out the decommissioning project, updating all relevant documentation and communicating completion to stakeholders.

5.4.4 Roles and Responsibilities¶

The successful decommissioning of the legacy eMap system requires coordinated effort from various teams:

• Project Management: Oversees the EOL plan, manages the schedule, coordinates resources and communicates with stakeholders.
• Cloud Infrastructure Engineers Responsible for shutting down servers, de-provisioning VMs and storage, cleaning up network configurations and reclaiming cloud resources.
• GIS Engineers: Assist with final data reconciliation, advise on legacy service configurations and support any technical queries related to ArcGIS components during decommissioning.
• Database Administrators: Perform final database backups, assist with database server shutdown and manage archival of database backups.
• Cybersecurity Engineers: Oversee secure data handling during archival, validate secure decommissioning of infrastructure and ensures compliance with security policies.
• Data Owners/Stewards: Provide final sign-off for data migration completeness and authorise the archival of the legacy data according to retention policies.
• Change Management/Communications Team: Manage all stakeholder communications regarding the EOL plan, schedule and user impact.