Migrating from Azure Spatial Anchors

The fully offline ASA alternative: anchors from room geometry, no cloud service to retire.

Azure Spatial Anchors has been retired. If you built on it, your anchors lived in Microsoft’s cloud, and they went away with the service. LansAnchor is a replacement built on the opposite premise. The anchor is a file that stays on your devices, matched against local mesh geometry, with no service in the loop at all. There is nothing to retire, because there is nothing running.

Jump to: What you lose | Concept mapping | The limits | Migration steps

What you lose with ASA gone

Cloud anchor storage: every anchor you created lived on Azure; the spatial data behind it is not exportable into another system.
The ASA SDK: CloudSpatialAnchorSession, CreateAnchorAsync, AnchorLocateCriteria and the watcher/event flow around them have no upstream anymore.
Cross-device localization via Azure: devices found each other’s anchors by querying the same cloud map.

The anchors themselves cannot be migrated. ASA never exposed the underlying spatial data. What migrates is your app’s anchoring flow: re-scan, re-place, and the concepts map cleanly, below.

What the VPS alternatives ask of you

The cloud-VPS replacements pitched to ASA refugees share ASA’s basic shape, and its basic risk:

Camera frames leave the device on localization. On standard tiers, a device localizes by capturing frames and sending them to a cloud map-query endpoint. Where offline localization exists, map creation still runs on the vendor’s cloud from uploaded camera images. Or offline is an enterprise-only line item with no public docs or price.
Mapping is a workflow. A dedicated scanning app or professional-scanner import, image uploads with overlap rules, a cloud map-build step that can fail and be redone.
Maps and queries are metered. Per-map limits, area limits, API-call quotas: your anchors live in an account-bound dashboard on someone else’s infrastructure, the exact dependency ASA just taught everyone about.

LansAnchor’s answer: no mapping service, no upload queue, no image-overlap rules. The input is the spatial mesh your device already builds. No camera image ever leaves the device; anchors are computed from geometry alone (positions and normals). The anchor is a file you own, typically 2-5 MB, shared over any channel you already trust.

Concept mapping: ASA to LansAnchor

Azure Spatial Anchors	LansAnchor
`CloudSpatialAnchorSession` + watcher setup	No session object: `AnchorCreationFlow`/`LocalizationFlow` (or `ManualAnchoring`) call synchronous local registration.
`CreateAnchorAsync` (writes to Azure)	`PlaceAnchorAsync()`/`TryCreateAnchor()` builds an `AnchorPayload` on-device; you transport the file yourself.
`AnchorLocateCriteria` + watcher `Located` event	`Localize()`/`StartLocalizing()` returns a result directly: `Matched`, `Ambiguous`, or `NoMatch`.
Cloud anchor ID, resolved by Azure	The `AnchorPayload`/`AnchorBatch` file itself; no ID to resolve against a server.
Locate-strategy/distance tuning	A `CertaintyTier` (`Rejected`/`Tentative`/`Confident`) on every `Matched` result, so borderline finds get hedged in your UI instead.
Per-room anchor sets, near-device criteria	A `RoomSourceEntry` list keyed by `RoomId`, matched against several rooms in one call. See multi-room anchoring.
Spatial data stored in Azure’s map	Mesh features only: positions, normals, curvature/edge/gravity descriptors. No images, no reconstructable point cloud.

What actually gets rebuilt vs reused

There is no automated importer from ASA and none is planned; the cloud-side spatial data was never exportable, so there is nothing to convert.

Deleted outright: session setup, account keys, watcher plumbing, retry/backoff logic built around ASA’s async locate events.
Rebuilt, not ported: the save and find calls themselves, against AnchorCreationFlow/ LocalizationFlow (scan-strength meter and retry loop built in) or ManualAnchoring/ MultiRoomAnchoring for a simpler entry point. See your own AR Foundation app for the full wiring.
Reused close to as-is: your app’s UX around anchoring, the “tap to place” button, the scanning prompt, a room picker. None of that depended on ASA internally.
Physically required: every anchor gets re-placed from a fresh scan, once, per space. No shortcut around that step on any migration path.

The honest differences

This is not ASA with the logo swapped. The architecture is different, and the differences cut both ways:

Mesh geometry, not visual features. Matching runs on the room’s shape (positions and normals), not camera imagery. That means it works in the dark on depth-only capture (see offline by design). It also means feature-poor spaces, like a bare symmetric room, are harder for it than for a visual system.
No cloud persistence at all, by design. We do not offer hosted anchor storage, and that is the point, not a missing feature. The payload is a file; where it lives is your call. Nothing we run can be shut down under your app, because matching never touches our infrastructure.
Works in air-gapped and no-connectivity sites. Basements, aircraft, defense and healthcare environments where a cloud round-trip is a non-starter. Finding an anchor is a local computation, so connectivity is irrelevant.
What a cloud service can do that this cannot: server-side map merging across many users, a shared global map that grows as devices contribute. If your product depends on that, a cloud-VPS vendor is the honest recommendation.
Verified, or not reported. Every match passes hard verification gates before it is ever returned. A 50-attempt adversarial gauntlet against one canonical scan per building came back 50/50 correct rejections. Confident-wrong results do exist in the wider real-scan corpus, and we measure and publish that rate rather than quote only the number that looks best. See how it knows it’s right.

The limits, unhidden

Same-app, same-device-family sharing is the proven path today. The one cross-app pair measured (two different iPhone LiDAR scanning apps of the same room) passes every verification gate individually in both directions. But bidirectional consistency between the two apps missed its own budget. Do not build cross-app anchor sharing on this yet; see Diagnostics for the exact numbers.
Accuracy is designed for 2-4 cm anchor-local, measured at 2.5-3.6 cm RMSE on real cross-scan room pairs. That RMSE is a lower bound on felt error, not a guarantee. Tape-measure checks on real finds have shown gaps of roughly 2x to 4x above the logged number. See what 2-4 cm actually means for the full breakdown, including the scans where it does not hit that target.
Room-scale guidance: place the anchor near a distinctive corner or edge rather than a blank wall. Lower the anchor-collection radius to 1-2 m on flat surfaces, so features cluster where the geometry is actually distinctive. A stress sweep found registration failure clusters at low shared overlap between the two scans, roughly 20% or less. Scan generously around the anchor spot, not just the anchor point itself, on both the placing and finding device.

Migration steps, sketched

Add the package

Add our scoped registry to Packages/manifest.json and install com.lansenou.unitybridge. The exact snippet is in the quick start.

Replace the ASA session code

Delete the CloudSpatialAnchorSession setup, account keys, and watcher plumbing. In its place there are two calls: a save call where you created cloud anchors (scan, place, payload builds automatically), and a find call where you located them (import the payload, register against the local scan). The AR Foundation sample shows the full scan-place-save-share-find flow on device.

Move the payload yourself

Where ASA resolved anchor IDs through Azure, you now transport a payload file (typically 2-5 MB) between devices: through your existing backend, a share sheet, or any channel you already trust. The pipeline does not care how it travels.

Re-create your anchors

ASA’s spatial data is not exportable, so anchors are re-placed, not imported: scan each space once, place the anchor, save the payload. From then on any device finds it from its own independent scan.

Shipped apps run free forever: no runtime license check, no service dependency, nothing we could ever turn off. Licensing applies to developers, not your users. That is the structural answer to the ASA retirement, not a pricing promise.

Trial availability, plainly

A free trial is available today, same code path the product will use later (see licensing).

Start a free trial: no card. Or register interest to hear about what comes next.