A phased ArcGIS to Open GIS migration plan

A workable ArcGIS migration plan moves complete workflows in dependency order. It does not begin by choosing a replacement product for every Esri logo. Start with one business operation, prove its data and consumer behavior, assign its operator, and then expand. QGIS, PostGIS, GeoServer and pygeoapi solve different parts of that operation.

This execution guide is designed for organizations in Spanish-speaking Latin America and bilingual delivery teams. It covers inventory, architecture, pilot, coexistence, batch migration and retirement. Durations depend on data quality and application dependencies; the sequence below is not a fixed implementation quote.

Phase 1: establish scope and the current reference

Responsible people: a business owner who knows the required result, a GIS specialist who can reproduce it, and the people responsible for applications, data and operations. One person may hold multiple roles in a small team, but every responsibility still needs coverage.

Inventory workflows rather than just files. “Monthly asset report” should point to its input layers, joins, script, scheduled account, map template, recipient and deadline. Include annual or emergency tasks that will not appear in one week's logs. Identify contractual outputs, field campaigns and renewals that constrain the schedule.

Use the migration inventory CSV. Its columns cover owner, source, consumers, authentication, CRS, editing, offline use, attachments, automation, availability, candidate approach, acceptance evidence and rollback condition. Fill unknowns with a named investigation instead of silently assuming they are unnecessary.

Preserve original outputs and a recoverable data copy. A reference map, a known query result and a representative report provide a basis for comparison. Do not alter a production geodatabase merely to discover whether conversion is reversible.

Phase output: a bounded first workflow with consumers, measurable expected results, current cost and the dependencies it must retain. For larger deployments, draw the dependency order: data before services, services before applications, applications before user cutover.

Phase 2: assign component responsibilities

Choose components by the contract they must provide. A desktop editor is not an identity service; a feature API is not a portal; a spatial database does not automatically recreate Esri versioning.

Use the enterprise capability comparison when portal sharing, branch versioning or specialist applications are in scope. Record four decisions for every dependency: configure, integrate, rebuild or retain. “Supported by open source” is not a delivery estimate.

Phase output: a small architecture showing the authoritative store, editing path, read-only publications, identity boundary and operator. Select version combinations and deployment approach before creating production configuration.

Phase 3: prove an end-to-end slice

The pilot must carry data from input through an actual user action. For an asset inventory: load records, inspect them in QGIS, edit an allowed attribute, publish a map and feature endpoint, consume them in an application and restore the data. Include a remaining ArcGIS client when coexistence requires it.

Start with the downloadable lab to make the protocol and data checks concrete. It contains 10,000 synthetic assets, stable asset_id values, predictable districts, a QGIS project, service configuration and acceptance worksheets. These inputs allow exact expected results without exposing customer data.

Examples of acceptance statements for this fixture:

• There are 10,000 distinct asset identifiers; asset-00001 remains the same business record after export.
• Filtering district=D01 returns 1,000 records with the fixture's distribution.
• The documented bounding box returns 441 fixture points, using the declared CRS and axis order.
• A read-only role cannot update records; an editor cannot change fields outside its permitted scope.
• A restore into a disposable database reproduces counts, identifiers and attributes.

These statements are requirements to test, not an assertion that every supplied path has been executed. The lab records actual local pygeoapi CSV and GeoServer Shapefile checks. Its PostGIS container path and QGIS desktop project require execution in your environment. Local measurements are not production capacity estimates, and the different server workloads are not a head-to-head benchmark.

After the educational fixture, repeat the slice on an authorized representative sample. Include a difficult geometry, a null value, a long text field, a non-ASCII label and an attachment when the real workflow uses them. Select a complete relational subset; a random feature sample can omit related rows and produce misleading failures.

Phase output: a user completes the named task, differences are documented, critical errors are resolved, and the operating team demonstrates recovery. Measure task time and support effort to improve the cost estimate.

Phase 4: design coexistence and reconcile change

Assign exactly one authoritative editing path per dataset or explicitly separated partition. A frequent pattern is retaining specialized Esri editing while publishing controlled read-only derivatives to open services. Another is moving a portable inventory to PostGIS while keeping unrelated datasets in their original system.

Do not let two disconnected exports accept edits without a reconciliation design. Define stable keys, update timestamps, deletion representation, refresh frequency and failure behavior. Specify whether synchronization is a full snapshot or incremental; a snapshot that silently omits deleted records can leave stale assets in a downstream application.

Define the last write accepted by the old workflow and how later writes reach the new one. A rollback plan must account for edits created after cutover, not merely point DNS back to yesterday's database.

Phase output: a written update sequence and a rehearsed failed-refresh/recovery exercise, with one clear source of truth at each stage.

Phase 5: confirm economics and the operating model

Use pilot observations to update the cost model. Include retained licenses, operators, support, backups, storage growth, training and temporary overlap. If an expected saving depends on halving support hours, state the measurement that would justify it.

Agree maintenance coverage, incident ownership, escalation, backup frequency and a recovery objective appropriate to the workflow. Test restoration rather than reporting only that backups exist. Check access removal, credential rotation, security updates and the effect of an unavailable upstream service.

A credible production handover includes configuration without secrets, dependency versions, deployment instructions, a dataset ownership list, service contracts and a recovery procedure that another operator has followed. Store credentials through the organization's existing secret-management approach, not in exported project files or a public configuration repository.

Phase output: an affordable operating arrangement and explicit decision to proceed, narrow scope or retain the existing workflow. A successful demo does not require a financially unfavorable migration to continue.

Phase 6: migrate in reversible batches

Group work by shared data and consumer dependencies. A low-risk first batch often consists of public read-only publication with well-understood inputs; it is not necessarily the batch with the fewest files. Keep specialist editing and offline synchronization separate until their tests pass.

For each batch, perform the same sequence: preserve the source, run the transformation, reconcile identifiers and values, test clients, train users on their actual task, schedule the switch, and observe the new operation. Set the rollback condition before the switch. Examples include missing records, failed authorization or an agreed service-time limit; thresholds must come from the real business need.

If rollback occurs, stop new edits on the affected path, preserve the new changes, identify the last consistent state and reconcile before reopening. Simply restoring an older backup can erase valid work. Rehearse this with disposable data so people know their responsibilities under pressure.

Phase output: one operational batch with its consumers switched and new changes accounted for. Use its defects and measured effort to size the next batch, rather than multiplying a best-case demo time by the number of layers.

Phase 7: retire dependencies and measure the outcome

Before retiring a service, inspect consumers, scheduled jobs, shared links and infrequent reporting tasks. Export required data and configurations in usable formats. Confirm the renewal change with the contract owner and preserve any required access to retained capabilities.

Measure at a defined follow-up period: actual invoices, operating hours, failed jobs, restoration results and user task completion. Compare like-for-like scope. If the organization gains a useful API at the same cost, describe that result directly. Do not relabel increased capability as observed monetary savings.

A completed migration leaves a functioning workflow, a prepared operator, recoverable data and a documented boundary for what remains on ArcGIS. The lab worksheets make the initial inventory and acceptance work concrete; the final production evidence must come from the organization's own tasks and environment.