5.1: Migration Plan

Successful transition from the legacy eMap system to the new eMap platform relies on a planning and executing a detailed migration strategy

5.1.1 Inventory of Legacy Data, Services, Applications, and User Workflows¶

Successful migration depends on good understanding of the existing system. The Dataset and Asset Register compiled during Phase I: Data Governance Framework serves as the critical input for this migration planning phase.

The effective use of this register involves:

1. Migration Validation: Prior to migration, the existing Dataset and Asset Register should be reviewed to ensure it captures all elements relevant to the migration. This includes:

   • Datasets: Full details on current data formats (e.g., shapefiles, file geodatabases, SQL Server tables), storage volumes, spatial reference systems, data quality assessments, identified dependencies between datasets, and crucially, their business criticality and current usage levels. This information is vital for estimating migration effort, planning data transformation, and scheduling.
   • Services: A complete catalogue of existing map services, feature services, geoprocessing services, and OGC-compliant services (if any). For each service, the register should detail its current endpoint, underlying data source(s), publishing parameters (e.g., caching settings, security), usage statistics and all known consuming applications or workflows. This helps in identifying services that can be directly re-published, those requiring re-architecture or those that can be decommissioned.
   • Applications: Documentation of all custom web applications, desktop tools, scripts, and ETLs that interact with the legacy eMap system. This includes details on their functionality, user base, underlying technology stack, and how they consume data or services.
   • User Workflows: Descriptions of key business processes and user workflows that rely on the legacy eMap platform. Understanding these workflows is essential for assessing user impact, planning training, and ensuring continuity of operations.
   • Integrations: Details of any integrations between the legacy eMap system and other enterprise or IRD-managed systems. These integrations represent high risk areas and need careful planning for recreation or modification.

2. Raster Data Migration Planning: A specific and critical component of the inventory is the detailed listing of all legacy raster datasets. As outlined in the Raster Data Storage Strategy, a phased migration of these formats (e.g., PNG, GeoTIFF, IMG) to cloud-optimised formats such as Cloud Raster Format (CRF) and Meta Raster Format (MRF) within Azure Data Lake Storage Gen2 (ADLSg2) is required. The inventory must capture format, size, usage, and suitability for conversion to CRF/MRF, which will heavily inform the effort and sequencing of raster data migration.

The Dataset and Asset Register will become the single source of truth for identifying the scope of the migration, understanding interdependencies and planning the transition of each component to the new eMap platform.

graph TD
    A[("🚀 Start: Migration")] --> B{"🗂️ Dataset & Asset Register<br>Available?"};
    B -- "✅ Yes" --> C[/"🔍 Validate Migration Inventory<br><small>Raster suitability • App dependencies • Service endpoints</small>"/];
    B -- "❌ No" --> X[("🛑 Critical Prerequisite Missing!<br>Complete Inventory First")];
    C --> D[/"📊 Prioritise Assets<br><small>Business criticality • User impact • Risk</small>"/];
    D --> E{"⚖️ Technical Dependencies<br>Analysed?"};
    E -- "✅ Yes" --> F[/"🗓️ Define Migration Waves<br><small>Pilot • Phased rollout • Quick wins</small>"/];
    E -- "❌ No" --> Y[("🔄 Refine Dependency Mapping")];
    Y --> D;
    F --> G[/"🚁 Execute Pilot Migration<br><small>Validate processes • Train team</small>"/];
    G --> H{"📈 Pilot Results<br>Acceptable?"};
    H -- "✅ Yes" --> I[/"📣 Develop Comms Strategy<br><small>Audiences • Channels • Training</small>"/];
    H -- "❌ No" --> Z[("🛠️ Adjust Migration Plan")];
    Z --> F;
    I --> J[/"👥 User Impact Analysis<br><small>Workflow changes • Downtime plans</small>"/];
    J --> K[/"⚙️ Technical Execution"/];
    K --> L{"🔄 More Batches<br>Remaining?"};
    L -- "✅ Yes" --> F;
    L -- "❌ No" --> M[("🏁 Migration Complete")];

    classDef halt fill:#ffcccc,stroke:#cc0000,stroke-width:2px;
    classDef process fill:#e6f3ff,stroke:#007fff,stroke-width:1px;
    classDef decision fill:#fff0b3,stroke:#ff9900,stroke-width:1px;

    class X,Y,Z halt;
    class B,E,H,L decision;
    class A,C,D,F,G,I,J,K,M process;

Diagram: High level migration planning process flow.

5.1.2 Prioritisation and Sequencing¶

Migrating an enterprise GIS platform is a complex undertaking. A phased approach to migration is essential to manage this complexity, mitigate risks and facilitate iterative learning. "Big bang" migrations are often fraught with peril and lead to extended downtime and user dissatisfaction.

The prioritisation and sequencing of migration components should be guided by the following criteria:

1. Business Criticality: Datasets, services, and applications that support mission critical business functions or regulatory requirements should receive higher priority. The impact of their unavailability guides this assessment.
2. User Impact: The number of users affected and the importance of the workflows supported by a particular component are key considerations. Migrating components with a broad user base or those underpinning essential daily tasks early can demonstrate value and build momentum.
3. Technical Dependencies: Understanding the interdependencies between datasets, services, and applications is crucial. Foundational datasets or services that other components rely on must be migrated and validated before their dependents. This "dependency first" approach prevents cascading failures during migration.
4. Ease of Migration ("Quick Wins"): Identifying components that are relatively straightforward to migrate (e.g., simple services, well-structured datasets with minimal transformation needs) can provide early successes. These "quick wins" help build confidence in the migration process and provide valuable learning experiences for the team.
5. Data Volume and Complexity: The sheer volume of data and the complexity of data models or transformations required will significantly influence the time and effort for migration.
6. Risk Mitigation: Components of the legacy system that are known to be unstable, unsupported, or pose a security risk should be prioritised for earlier migration to reduce ongoing operational risk. Conversely, highly complex or poorly understood legacy components might be scheduled after the team has gained experience with simpler migrations.
7. Alignment with New Platform Capabilities: Priority may be given to migrating assets that can immediately benefit from the enhanced capabilities of the new eMap platform, such as improved performance from Azure PaaS data stores.

Based on these criteria, the migration may be structured as follows:

• Pilot Migrations: A small, representative batch of datasets, services and applications should be selected for an initial pilot migration.
• Phased Rollout: Subsequent migrations will be grouped into logical phases or batches. These batches might be defined by business function, data domain or technical stack.
• Iterative Refinement: Learnings from each pilot and migration phase should be incorporated into the planning and execution of subsequent phases.

A formal Migration Schedule should be developed and maintained, detailing the sequence of migration activities, timelines, responsibilities, and dependencies. This schedule will be a dynamic document, subject to review and adjustment as the migration progresses and should be made available to relevant stakeholders.

5.1.3 User Impact Assessment and Communication Strategy¶

A successful migration requires careful consideration of the impact on end users and a proactive communication strategy to manage expectations and ensure a smooth transition.

User Impact Assessment¶

Before migrating any component that affects end users, an impact assessment should be conducted:

1. Identifying Affected User Groups: Based on the Dataset and Asset Register and engaging with business unit representatives to identify user groups, roles, and specific individuals who interact with the legacy components scheduled for migration.
2. Analysing Workflow Changes: Documenting how user workflows will change post-migration. This includes:
   • Changes to application access URLs or service endpoints.
   • Modifications to user interfaces or application functionalities.
   • Differences in data access methods or data schemas.
   • Potential changes in performance characteristics.
   • Introduction of new features or retirement of obsolete ones.
3. Identifying Potential Disruptions: Transparently identifying and documenting any anticipated service downtime, periods of reduced functionality or other potential disruptions during the migration window for specific components.
4. Assessing Training Needs: Determining the level of retraining or new training required for users to effectively use the new eMap platform.

The findings of the user impact assessment for each migration batch should be documented and used to inform the communication and training plans.

Communication Strategy¶

A proactive, clear and consistent communication strategy is vital to keep all stakeholders informed, manage expectations, minimise resistance to change and drive adoption of the new eMap platform:

1. Target Audiences: Communications should be tailored to different stakeholder groups, including:
   • General end users of GIS services and applications.
   • Power users and GIS specialists within business units.
   • Departmental managers and Executives.
   • Internal Service Desk.
2. Key Messages: Communications should consistently convey:
   • The benefits of the new eMap platform.
   • What is changing for specific user groups as a result of each migration phase.
   • When changes are scheduled to occur, including any planned maintenance windows or potential service interruptions.
   • How users can access training materials, support resources, and provide feedback.
3. Communication Channels: A multi-channel approach should be used to ensure broad reach:
   • Targeted email notifications to affected user groups.
   • Presentations and Q&A sessions during team meetings or dedicated migration briefings.
   • Regular updates in project newsletters or status reports.
   • Clearly signposted FAQs and knowledge articles.
4. Timing and Frequency:
   • Early Communication: Announce the overall migration strategy and timeline well in advance.
   • Pre Migration Notifications: Provide specific details about upcoming migration batches including dates, expected impacts and actions users may need to take.
   • During Migration Updates: Communicate progress and any unexpected issues or delays.
   • Post Migration Confirmation: Announce the successful completion of migration batches and provide guidance on accessing the new services/applications.
5. Feedback Mechanisms: Establish clear channels for users to:
   • Ask questions about the migration process or the new platform.
   • Report any issues encountered post migration.
   • Provide feedback on their experience with the new eMap system.

Training and Support¶

The migration process requires ongoing and targeted training efforts. As new services and datasets are migrated or redeveloped on the eMap platform, specific training modules or refresher sessions should be provided to ensure users remain proficient.

This migration plan aims to deliver a smooth transition to the modernised new eMap platform.