NSW Point switches off 30 September 2026. Here's your migration decision tree.
If any system in your estate validates or geocodes addresses through NSW Point V2 — directly, via the NSW Address Widget, or through a product that quietly uses it underneath — you have a dated, non-negotiable migration on your hands. Per the official NSW Point documentation: "NSW Point V2 is in a mature state and will be decommissioned on 30 September 2026." There is precedent for the deadline being real: NSW Point V1 was decommissioned on 30 June 2023, after which V1 applications were no longer supported.
What NSW Point actually is (and isn't)
NSW Point is the NSW Government's address validation service, built on Geoscape API technology over the authoritative GNAF, GNAF-Live and MailAddress datasets. It's more than a geocoder: the Predictive1 service powers type-ahead suggestion, Predictive2 returns full address and location detail on selection (including LGA name, ABS statistical areas SA1–SA4, mesh block, state electorate, cadastral parcels and delivery point identifier), MailPoint validates postal addresses, and separate services expose administrative boundaries and NSW cadastral parcels. API keys are issued per application, each with its own throttle limits.
Two facts that get misremembered: NSW Point is not free — fees have applied to NSW Point API services since 1 July 2024 — and it is not disappearing. NSW Point V3 is the successor (Address, Coordinate, Cadastral Parcel and Property products). What goes away on 30 September 2026 is the V2 endpoint and the V2 request/response contract every existing integration was built against.
The four paths
Path 1 — Migrate each system to NSW Point V3
The official route. V3 is a different API surface, so each consuming system needs its integration rebuilt and re-tested against the V3 contract, with new keys requested through the V3 access process. Right answer for a single consuming system that's happy staying on NSW Point — but the rebuild cost multiplies per system, and V2→V3 is precisely the kind of contract change (the second in three years, after V1→V2) that per-system integrations keep paying for.
Path 2 — Direct Geoscape contract, per system
Go to the source: NSW Point runs on Geoscape technology, and Geoscape sells its Predictive and Address APIs directly. Contract-based access — there is no public per-call rate card — so every additional system multiplies both the integration rebuild and the commercial admin.
Path 3 — A commercial validation SaaS
Global address-verification vendors will happily take the workload. What they won't give you: authoritative-first routing with the enrichment attributes AU government workflows actually need (LGA, electorate, cadastre linkage — the very fields NSW Point's Predictive2 returns), or field-mapping into SAP Business Partner / Maximo / TechnologyOne structures. You'll also be re-solving the licence question — several global providers restrict storing results, which matters when the address is going into a permanent asset register.
Path 4 — An aggregation layer (migrate once, not N times)
Put one internal contract in front of all consuming systems, and absorb provider change behind it. This is what AddressIQ does inside mapERP/AssetIQ — and NSW Point is itself one of the routed endpoints: the Australian chain runs G-NAF, then NSW Point, then global fallbacks. The routing engine carries NSW Point V2's sunset date and stops routing to it automatically on 30 September 2026 (or switches to V3 the day your V3 keys are configured — a config change, not a project). Consuming systems — SAP, Salesforce, ServiceNow, Oracle, Maximo, TechnologyOne — never see the difference. Every call is metered for cost attribution, and each ERP's field mapping ships as configuration.
The decision tree
- One consuming system, staying in the NSW Point ecosystem? → Path 1. Rebuild against V3 once, done.
- One system, wanting broader-than-NSW-Point coverage? → Path 2. Contract Geoscape directly.
- Multiple systems, but addresses are incidental (marketing lists, not assets)? → Path 3 may be adequate. Check the storage licence terms carefully.
- Multiple systems, addresses feed asset registers / works / dispatch, enrichment matters? → Path 4. The migration is done once, NSW Point (then V3) stays in the chain as an endpoint, and licence/billing governance moves to a layer your architecture team controls.
Timeline reality check
Working back from 30 September 2026: a per-system rebuild needs discovery, V3 (or Geoscape) onboarding, build, test and cutover — per system. If you have three or more consuming systems and haven't started, the per-system path is already tight. The aggregation path parallelises better because consuming systems only re-point to one internal contract; the single V3/Geoscape integration is the critical path.
Ask your team one question this week: "Which of our systems call NSW Point, directly or indirectly?" If the answer takes more than a day to produce, that discovery gap is itself the strongest argument for consolidating to one governed layer.