Navigating the Move to TechOne OneCouncil: Strategy, Lessons Learned and a Real-World Integration Example

Navigating the Move to TechOne OneCouncil:

Strategy, Lessons Learned and a Real-World Integration Example

As councils continue to transition from on-premises TechnologyOne environments to the OneCouncil cloud platform, many are finding that integration approaches that worked successfully for years need to evolve.

In this collaborative blog, Michael Studdert Pre-Sales Consultant & Account Manager, shares her observations from working with local government organisations undertaking this transition, while Belinda Kerr, Senior Consultant, provides a practical example from a OneCouncil implementation at Sutherland Shire Council using ArcGIS, FME and Python.

A Changing Integration Landscape

By Michael Studdert, Pre-Sales Consultant & Account Manager 1Spatial by VertiGIS

Over the past few years, I've had a front-row seat to how councils across Australia are rethinking their TechOne integrations, with most of my customers operating within local government.

The standard approach with TechOne on-premises was direct database connectivity. Everything sat on the council's own network, allowing teams to connect directly into SQL databases, run queries, perform scheduled extracts and build integrations around the data they needed. FTP often played an important role during hybrid environments and migration projects, providing a practical way to bridge systems while organisations transitioned from on-premises to cloud solutions. It remains a useful approach in some situations today.

As councils move further into the cloud platform, API-based integration is increasingly becoming the preferred approach. It is more maintainable, more scalable and aligns with the architecture of modern cloud environments. In an API-first world, it makes sense to build integrations that way.

However, getting there has not always been straightforward.

REST APIs, OAuth authentication and web service-based integrations require a different way of thinking compared to direct database access. What appears on the surface to be a relatively straightforward process of connecting, authenticating, extracting, transforming and loading data can quickly become more challenging when organisations are navigating unfamiliar technologies and documentation.

A significant challenge has been the lack of a single, comprehensive source of information. Every council seems to encounter something slightly different: an endpoint behaving unexpectedly, module-specific limitations or unique configuration requirements that only become visible during implementation. Because CI Anywhere remains relatively new for many organisations, there is still a level of discovery involved in every project.

What has stood out most to me is how much faster progress happens when councils share their experiences. Some organisations have already solved problems others are only just encountering, and collaboration continues to be one of the most valuable tools available when planning a migration to OneCouncil. Real success doesn't come from a single product or technique. It comes from organisations being open about what works, what doesn't and what lessons have been learned along the way.

A Practical OneCouncil Integration Example

By Belinda Kerr, Senior Consultant at 1Spatial By VertiGIS

The OneCouncil configuration at Sutherland Shire Council (SSC) for the Assets and Property & Rating modules involved a combination of ArcGIS, FME and Python scripting.

A key driver of the configuration was the use of web services wherever possible for synchronising and extracting data from OneCouncil. The solution also needed to replicate existing overnight processes previously driven from the on-premises Property & Rating SQL database and Confirm asset management system.

These overnight extracts supported numerous business needs, including internal web mapping applications, reporting and downstream analysis.

Syncing Data into OneCouncil

Asset Management

For the Asset module, SSC established OneCouncil as the source of truth for non-spatial information, while GIS remained the source of truth for spatial data.

This approach substantially reduced the amount of information that needed to be synchronised daily.

Key elements of the configuration included:

• Each asset classification was linked to a dedicated GIS layer configured in OneCouncil.
• ArcGIS map services were used as the integration endpoint, with a single service containing all asset layers requiring synchronisation.
• Editor tracking was enabled on underlying feature classes to identify recently modified assets.
• Definition queries filtered records modified within the previous seven days to minimise processing volumes.
• Asset Spatial Processing jobs in OneCouncil synchronised geometry updates nightly.
• Stormwater assets required additional configuration where both spatial and selected non-spatial information originated in GIS. ArcGIS domains and subtypes were aligned with OneCouncil requirements to ensure successful synchronisation.

This approach provided reliable synchronisation while allowing sufficient time to investigate and resolve any issues before records dropped from the synchronisation window.

Property and Rating

The Property and Rating module introduced additional complexity.

Unlike the Asset module, only spatial information for Land, Property and Streets can be synchronised directly into OneCouncil. All non-spatial information is imported via worksheet templates.

To support this process, SSC implemented a similar architecture to the asset integration, using ArcGIS map services and definition queries to identify recently modified polygons.

However, the spatial import process has strict requirements.

Imports require OGC-compliant geometry and do not support:

• True curves
• Excessive vertex counts
• Duplicate key identifiers

SSC's cadastral data contained several of these challenges, including curved geometry, complex polygons and duplicate identifiers that required consolidation into multipart features.

To overcome these issues, Python scripts were developed to:

• Cleanse cadastral and street data.
• Convert geometry to OGC-compliant formats.
• Merge polygons that shared common identifiers.
• Automatically generate the required property layers.

While FME could have been used to perform these transformations, overnight processing constraints and limited engine availability made Python the more practical solution for this specific workflow.

Once configured, Land, Property and Street spatial imports were scheduled to run nightly, ensuring maps, property information and neighbour notification functions within OneCouncil remained current.

Managing Additional Information

Another important component of the SSC implementation was Additional Information (formerly known as Attributes in Property & Rating).

SSC maintains a long-standing process known internally as "the matrix", which has been supporting planning and property attribute management for more than 20 years.

Today, the process uses ArcGIS Pro and Python scripts to generate import files in the format required by OneCouncil worksheet imports.

Through a OneCouncil dashboard, users can run ETL processes that automatically import these updates into the system.

The key lesson is that OneCouncil is flexible regarding how import files are generated. Whether using Python, FME or another process, the critical requirement is ensuring outputs conform to the expected worksheet structure.

Extracting Data from OneCouncil

For both Assets and Property & Rating, SSC followed a consistent approach for data extraction:

1)   Write data models that contain the information needed – this is the tricky part as you really need to know what is stored in the backend tables. SSC utilised external resources to assist here due to limited experience with the new schema and limited time frames.

2)   Turn the data model into a web service – see the webinar Q&A’s for some more info on how to do this.

3)   Extract the information from the web service using FME, saving all outputs to the spatial geodatabase as SQL tables.

4)   Use an FME Flow automation to run each FME workbench back to back as there was only 1 engine to work with.

Because SSC operated with a single FME engine, automation was essential for ensuring multiple overnight processes could run successfully without resource conflicts.

Bringing Strategy and Implementation Together

Michael's experience highlights the broader shift councils are experiencing as they move from traditional database-driven integrations to modern, API-based architectures. Meanwhile, Belinda's implementation at Sutherland Shire Council demonstrates how those concepts can be applied in practice using OneCouncil, ArcGIS, FME and Python.

Together, these perspectives reinforce a common theme: successful OneCouncil integrations require not only the right technology, but also a clear understanding of business processes, data governance and modern integration methodologies.

Most importantly, councils continue to benefit from sharing experiences and lessons learned as the local government sector collectively navigates this transition to cloud-first platforms.

Continuing the Conversation