A Smallworld upgrade moves a GE Vernova Smallworld deployment from version 4.x or an earlier release to version 5.x, the current supported architecture. It is not a software update. It is a structured engineering program that involves schema migration, custom Magik code rewrites, Physical Network Inventory (PNI) data validation, integration retesting across every system connected to the GIS, and parallel environment management before cutover.
Gnapi Technologies delivers Smallworld upgrade services and globally, managing the full program from scoping through go-live, for electric utilities, gas operators, and telecoms whose Smallworld deployments are approaching version end-of-life or are already running on unsupported releases.
Book An Appointment Now
Smallworld 5.x introduced modular architecture, REST-based web services, and a modernized Magik API
Enterprise Smallworld upgrades typically take 12–24 months depending on custom code volume and integration complexity
The highest-risk workstreams are schema migration, PNI data validation, and OMS integration retesting
Gnapi Technologies has delivered Smallworld upgrades for utilities with millions of network records
Delivery model: onshore program leads with offshore Magik engineering teams
Smallworld 4.3 is approaching the end of its supported lifecycle. GE Vernova’s investment in platform development, security patching, and technical support is concentrated on Smallworld 5.x, which means utilities and telecoms running 4.x deployments are accumulating technical risk with every year they remain on the older version.
Beyond the support trajectory, Smallworld 5.x offers meaningful operational improvements: modular architecture that is easier to maintain and integrate, REST-based web services through GSS that allow Smallworld data to be consumed by field crew applications and third-party platforms, a modernized Magik API that reduces the complexity of custom code, and improved integration patterns for OMS, ADMS, and mobile applications.
The question for most organizations is not whether to upgrade but when and how and the how is where the engineering complexity lives.
The Smallworld spatial database stores network data according to a schema, the structure that defines how assets, attributes, and relationships are organized. Smallworld 5.x introduced changes to how schemas are structured and how data is stored. Schema migration involves mapping every element of the existing 4.x schema to its 5.x equivalent, identifying where the mapping is straightforward and where it requires redesign, and executing the migration in a way that preserves data integrity throughout.
Schema migration for a large utility with decades of accumulated network data is one of the most technically demanding workstreams in the upgrade. Data quality issues in the 4.x schema become schema migration problems, which is why Gnapi Technologies assesses source data quality before migration begins, not after the first migration attempt fails.
Most Smallworld deployments contain significant volumes of custom Magik code written over years of platform use to extend Electric Office or Gas Distribution Office functionality, automate workflows, or build integrations. This code needs to be assessed, rewritten, and tested against the Smallworld 5.x Magik API before the upgrade can proceed.
Gnapi Technologies audits existing Magik code bases before rewriting begins, identifying which code is still actively used, which has become redundant, and which can be consolidated. Reducing custom Magik volume before rewriting it reduces the migration workload and the ongoing maintenance burden after the upgrade.
Physical Network Inventory (PNI) stores every physical asset in the network and how those assets connect. During a Smallworld upgrade, PNI schema migration is typically the highest-risk single workstream because PNI data feeds OMS, work management, and field crew systems. Errors in PNI after migration propagate into every system that depends on accurate network topology.
Gnapi Technologies runs PNI topology validation before migration begins, checking connectivity, asset attribute completeness, and topology rule compliance and runs it again after migration to confirm that the migrated data matches the source in every relevant respect.
A Smallworld deployment in a production utility environment is connected to multiple downstream systems: OMS, ADMS, CIS, SCADA, work management, mobile field crew applications, and reporting platforms. Each of these integrations needs to be retested after the upgrade, because schema changes, API changes, and GSS configuration changes in Smallworld 5.x affect how data is exposed and consumed.
Integration retesting is not a final check at the end of the program. It runs in parallel with schema migration, and Magik rewrites identifying integration failures early enough to address them before cutover.
Before a production Smallworld environment is cut over to version 5.x, a parallel environment runs both versions simultaneously, allowing the organization to validate that the 5.x environment produces the same operational outputs as the 4.x environment before the old version is retired. Managing a parallel environment across an enterprise GIS deployment requires significant operational discipline and coordination with every team that depends on the GIS.
Data quality issues discovered during migration
PNI topology errors, schema inconsistencies, and missing attributes that were masked in the 4.x environment become blocking issues during migration. Assessing data quality before migration begins is not optional.
Custom Magik code volume
Organizations that have accumulated large volumes of custom Magik code over years of platform use often underestimate the rewrite effort. Gnapi Technologies audits code volume before scoping, not after contract signature.
Integration complexity
Utilities with many downstream systems connected to Smallworld face the longest integration retesting programs. Each integration needs to be assessed, not assumed.
Timeline pressure
Smallworld upgrades are frequently scoped optimistically. Gnapi Technologies scopes what the program actually requires, including the risk, the data quality issues, and the integration complexity before any timeline is committed.
Most Smallworld upgrade programs run as fixed-scope delivery defined workstreams, timeline, and team composition agreed before the program begins, with clear milestones and a structured change management process for scope changes that arise during delivery. Some programs include a time-and-materials phase for Magik development work where scope evolves as the code audit progresses.
After go-live, most clients transition to a dedicated extended team arrangement for ongoing Smallworld 5.x support, minor enhancements, and capacity for post-upgrade integration work.
Smallworld Upgrade Services: Delivered by Engineers Who Have Done It Before
A Smallworld upgrade is not a project to scope optimistically and discover the real complexity halfway through. Gnapi Technologies delivers Smallworld upgrade services globally, starting with an honest technical assessment of what the program involves before any commitment is made. If you are planning a Smallworld 4.x to 5.x upgrade or assessing what an upgrade would require, start with a technical conversation.
Talk to a Gnapi Technologies Smallworld engineer.
Enterprise Smallworld upgrades typically take 12–24 months, depending on the volume of custom Magik code, the complexity of the PNI schema, the number of downstream integrations, and the quality of existing network data. Deployments with large volumes of custom code or significant PNI data quality issues take longer. Gnapi Technologies scopes each program individually based on a technical assessment of the source environment.
Schema migration restructures how network data is stored in the Smallworld spatial database, mapping every element of the existing 4.x schema to its 5.x equivalent, identifying where redesign is required, and executing the migration while preserving data integrity. It is one of the most technically demanding workstreams in a Smallworld upgrade, particularly for utilities with decades of accumulated network data and accumulated data quality issues.
Physical Network Inventory (PNI) data feeds the OMS, work management, and field crew systems that utilities and telecoms operate on. Topology errors in PNI after migration propagate into every downstream system that depends on accurate network data, affecting outage restoration, switching order logic, and field crew dispatch. Gnapi Technologies validates PNI before migration begins and again after migration to confirm integrity.
The volume of custom Magik that needs to be rewritten depends on how much has been written since the original deployment and how much of it is still actively used. Gnapi Technologies audits existing Magik code before rewriting begins, identifying what is in active use, what is redundant, and what can be consolidated, which reduces both the rewrite effort and the ongoing maintenance burden after the upgrade.
Every integration between Smallworld and downstream systems OMS, ADMS, CIS, SCADA, work management, mobile applications needs to be retested after the upgrade. Schema changes, API changes, and GSS configuration changes in Smallworld 5.x affect how data is exposed and consumed. Integration retesting runs in parallel with schema migration and Magik rewrites, not as a final check at the end of the program.
Parallel environment management runs both Smallworld 4.x and 5.x environments simultaneously before cutover, allowing the organization to validate that the 5.x environment produces the same operational outputs as the 4.x environment. It requires coordination with every team that depends on the GIS and significant operational discipline to manage data consistency between the two environments during the parallel period.
Yes, but the assessment phase is more extensive. Smallworld environments that have accumulated years of undocumented Magik code, unresolved data quality issues, and informal integrations require a thorough technical assessment before scoping can produce a realistic timeline and cost. Gnapi Technologies conducts this assessment as the first phase of every upgrade engagement.
This depends on the organization's existing integration investment, the complexity of the current Smallworld data model, internal skills, and long-term platform strategy. Some utilities are migrating to ArcGIS Utility Network. Many are investing in Smallworld 5.x. Some run both. Gnapi Technologies advises on this decision based on technical and operational factors without platform preference.
After go-live, most clients transition to a dedicated extended team arrangement. Gnapi Technologies provides ongoing Smallworld 5.x support, minor enhancements, version maintenance, and capacity for post-upgrade integration work. The team operates under the client's processes and tools, billed monthly, and can scale based on program demand.
The first step is a technical scoping conversation with one of our Smallworld engineers, not a proposal meeting. We ask about the current Smallworld version, the volume of custom Magik code, the downstream integrations, the PNI data quality situation, and the internal team capacity. From that conversation, Gnapi Technologies provides an honest view of effort, risk, timeline, and team composition. Contact Gnapi Technologies to book a call.
