Migrating to on8

Switch providers.
Without the downtime.

Import your monitoring lists, map your screening config to per-call parameters, dual-run on8.ai alongside your current provider, then cut over once you trust the results.

Import your monitoring lists

Enrol the entities you already monitor through the monitoring API, one POST .../monitoring/subjects call per entity. A batch job gives you a one-off baseline screen to compare with your incumbent, but it does not enrol anyone in monitoring. Use label for the source list so you can reconcile later.

Reconciliation runs on the same key: enrol with POST .../subjects, read the list back with GET .../subjects (filter it by your label with search), read the counts with GET .../stats, and receive alerts through the alert.created webhook. A key sees the subjects enrolled with API keys on your tenant, not the ones your team enrolled in the portal.

import.sh
curl --request POST \
  --url 'https://api.on8.ai/api/v1/portal/monitoring/subjects' \
  --header 'Authorization: ApiKey on8_3f9a12bc_••••••••' \
  --header 'Content-Type: application/json' \
  --data '{
    "query": "Acme Holdings SA",
    "schema": "Company",
    "country": "GB",
    "label": "legacy-list-A",
    "frequency": "Daily"
  }'

Dual-run and reconcile

Route a copy of live traffic to on8.ai while your incumbent stays authoritative. Compare match rates and false positives side by side until you are confident.

Shadow calls are metered against your plan’s monthly allowance like any other call, so while both systems run each subject is screened twice. Size the migration window with your account team. When the allowance runs out your plan decides what happens on the shadow leg: either calls stop with 402 QUOTA_EXCEEDED, which halts the comparison you are running, or they continue and the overage is billed.

Map your config

Express your thresholds with the per-call mode and threshold parameters, and keep your own decision rules in front of the API.

Diff the results

Run the comparison in fuzzy mode: there every hit carries a score, and source_records names the lists it came from, so divergences can be explained list by list before cutover.

Cut over with confidence

Once parity is proven, promote on8.ai to authoritative and decommission the legacy feed. Screening you run on on8.ai stays in the portal, queryable and exportable.

Decommissioning the feed is not the same as retiring the archive: migration moves your lists and config, not your history. Screening your incumbent ran before cutover stays with them, so keep those records for your statutory retention period.

See screening endpoints

Planning a migration?

Create an account and start dual-running today.

Start your migration