GE Smallworld Migration Planning: Moving to a Modern Utility Network Model

Why do utilities start a Smallworld migration?

Utilities start a Smallworld migration when the current system no longer fits their plans. In most cases, the network model is still sound. But the platform around it needs work.

Smallworld has a long record in network GIS for electric, gas, water and telecom firms. Today, GE Vernova positions GE Vernova Smallworld GNM (Geo Network Management) as the system of record that feeds its GridOS tools, such as ADMS and DERMS. However, many firms still run old releases with heavy custom code. So the gap to the current product grows each year.

In addition, grid change adds a further push. For example, Malaysia’s National Energy Transition Roadmap targets 70 percent of generation capacity from renewable sources by 2050. Therefore, network models must now hold far more rooftop solar, storage and EV charging.

Should you upgrade Smallworld in place or move to another platform?

For most Smallworld users, an upgrade to a current Smallworld GNM release is the lower risk path. A move to another platform makes sense only if a clear business reason justifies it. For instance, a group-wide GIS standard may require it.

GE Vernova has now launched Smallworld GNM 6.0. In particular, it says the release improves cyber readiness, usability and GridOS links. It also adds VMDS Cloud with PostgreSQL as part of a cloud path. As a result, staying on Smallworld no longer means staying on old servers.

How do you map a Smallworld data model to the target model?

Data model mapping says where every piece of source data will land in the target. In short, it is the key design document in a Smallworld migration. That is because every load, test and report depends on it.

Notably, Smallworld products such as Electric Office, Gas Distribution Office, Water Office and Global Transmission Office each have their own object models. In addition, most firms have extended these models over the years. So first, the team must record the model as it is built, not the vendor default.

What should a mapping spec cover?

• Object classes: each source feature type and its target match, including ones you will retire.
• Fields and value lists: names, data types, allowed values and default rules.
• Geometry: points, lines, areas, internal worlds and any schematic or text geometry.
• Network links: how terminals, manifolds and switch states turn into target topology, since ADMS depends on them.
• Relationships: ownership, containment and keys to other systems, for example SAP equipment numbers.

Next, agree the target model with the people who use it. For an electric firm, that means planners, field crews and control room staff, not just the GIS team. Also, if the target will share network models with ADMS, align the mapping with IEC 61968-13. That standard defines profiles for sharing network models in a utility. Our guide to geospatial electric network modelling explains why connections matter so much here.

Why should data cleansing happen before the migration?

Cleaning data before you move it is cheaper and safer than fixing it later. If bad data reaches the target, it spreads into ADMS, SAP and outage tools. Then every fix needs work across several systems.

First, run a profiling pass. In particular, it should count network breaks, orphan assets, duplicates, bad values and geometry errors. Then rank each issue by its effect on daily work. For instance, a broken feeder trace matters far more than a missing paint colour. Our article on data quality in GE Vernova Smallworld GNM covers common problem types.

However, some fixes need field proof. For example, missing transformer ratings or cable sizes may need a site visit. So plan that work early, because field work takes longer than desk edits. Independent GIS QA/QC checks also help, since the people who built the data are not always best placed to test it.

How does FME support a Smallworld migration?

FME lets a team build the extract, transform and load logic once and then rerun it for every trial and the final cutover. That repeat process is what keeps a large Smallworld migration under control.

Safe Software documentation lists a Smallworld 4/5 format in FME that both reads and writes data. But Safe notes that GE Smallworld and Spatial Business Systems build this reader and writer, not Safe itself. Also, it connects through an FME service that runs inside a Smallworld session.

1. Extract source objects and network links from the Smallworld datastore first.
2. Transform fields, values, geometry and topology as the mapping spec says.
3. Validate the output with scripted checks for counts, links and gaps.
4. Load into the target, then print match reports for sign-off.
5. Repeat the full chain for each trial load so that results become stable.

As an authorised FME partner, RedPlanet builds these workspaces through our FME services and wider GIS data migration work. However, version fit between FME and Smallworld is easy to miss. So check it at the design stage, not at the first load.

Which integrations need the most attention during a Smallworld migration?

Outage, ADMS, SAP and SCADA links need the most care, because each one needs a correct and complete network model. In fact, a GIS that looks right on screen can still break an outage call or a work order if one ID changes.

GE Vernova says Smallworld Electric Office helps close the old gap between GIS and ADMS without replacing existing systems. But that gain only holds if you retest each link end to end after the upgrade. Therefore, build a link test suite early and run it on every trial load.

Also, customer data needs extra care. In Malaysia, changes to the Personal Data Protection Act took effect in stages during 2025. In particular, these include breach notice rules and new guidance on sending data abroad. So if your move involves cloud hosting or offshore work on customer records, check the data flows with your legal team.

How should testing, parallel running and cutover work?

Testing should prove three things before go-live. The data is complete, the network is connected, and each user and system can do its job. Then a parallel run confirms this under real load, and cutover follows a rehearsed plan.

First, run several trial loads, each with a full match report. Next, compare feature counts, totals and trace results between source and target. Then ask business users to run normal tasks in the new system. For example, they might design a new connection or isolate a fault.

First, set a short edit freeze in the old system for cutover. Then run the final FME load, check the results and switch the links to the new system. Finally, keep the old system read-only for an agreed period. That way, users can check history if questions arise.

What timeline phases and risks should a Smallworld migration plan include?

A Smallworld migration usually moves through six phases, from review to support after go-live. However, length depends on data volume, custom code and the number of links. So plan by phase gates, not fixed dates.

Also, budget for training, because users who learnt Smallworld years ago will meet new screens. In addition, admins will meet new hosting and database options. For more on GIS in this sector, see our electric utility GIS page.

Frequently Asked Questions

What is the safest way to plan a Smallworld migration?

The safest Smallworld migration starts with an honest review and a clear choice. If your network model works, a current Smallworld GNM release is usually the lower risk route. A platform move can still be right, but only with its own model and link stream.

Either way, the same steps apply. First, agree the target data model. Next, clean the data before you move it. Then automate the loads with FME so each run is the same. Finally, test links early, run in parallel and cut over to a rehearsed plan. As a result, your field, asset and control room teams get a model they can trust from day one.