# Migrate from AWS Rekognition

> What is drop-in, what changes, the one step nobody can skip, and a six-step runbook for cutting over without a big-bang switch.

Source: https://sightradar.com/docs/guides/migrate-from-rekognition

SightRadar uses the same request and response shapes as AWS Rekognition for the face operations, so an existing integration keeps working. Pricing is pegged below the Rekognition Group-1 reference rate; see [pricing](/pricing).

## Operation mapping

| Rekognition                    | SightRadar                                                               |
| ------------------------------ | ------------------------------------------------------------------------ |
| `CreateCollection`             | `POST /v1/collections`                                                   |
| `ListCollections`              | `GET /v1/collections`                                                    |
| `DescribeCollection`           | `GET /v1/collections/{id}`                                               |
| `DeleteCollection`             | `DELETE /v1/collections/{id}`                                            |
| `IndexFaces`                   | `POST /v1/collections/{id}/index`                                        |
| `IndexFaces` with `MaxFaces=1` | `POST /v1/collections/{id}/selfies`                                      |
| `SearchFacesByImage`           | `POST /v1/collections/{id}/search`                                       |
| `SearchFaces` (by FaceId)      | `POST /v1/collections/{id}/search-by-id`                                 |
| `CompareFaces`                 | `POST /v1/compare`                                                       |
| `DetectFaces`                  | `POST /v1/detect`                                                        |
| `DeleteFaces`                  | `DELETE /v1/collections/{id}/photos/{photoId}` (per photo, not per face) |

Label detection, text detection, celebrity recognition and video are out of scope. SightRadar does face recognition only.

## What changes

* **Endpoint and auth.** `https://api.sightradar.com` with `Authorization: Bearer frs_…` instead of a regional endpoint with SigV4. No IAM users, roles or policies.
* **Scores.** Cosine similarity 0 to 1 instead of 0 to 100. The Python shim converts both ways; on raw REST you divide.
* **Bounding boxes.** Absolute pixels instead of ratios.
* **Image input.** URL, GCS key, multipart or raw bytes. `S3Object` becomes a URL you make fetchable.
* **Photos, not faces.** Results group to `photo_id`; the finest delete is per photo.

## Python: the two-line change

```python
from sightradar_rekognition_shim import client   # 1. swap the import

rek = client(api_key="frs_...")                    # 2. swap the constructor

rek.create_collection(CollectionId="event-2026")
rek.index_faces(CollectionId="event-2026", Image={"URL": "https://cdn.example.com/guest.jpg"}, ExternalImageId="guest-1")
res = rek.search_faces_by_image(CollectionId="event-2026", Image={"Bytes": open("selfie.jpg", "rb").read()}, FaceMatchThreshold=90, MaxFaces=5)
for m in res["FaceMatches"]:
    print(m["Face"]["ExternalImageId"], m["Similarity"])
```

The shim maps method names, argument shapes and response dictionaries (`FaceRecords`, `FaceMatches`, `Similarity`). Details and honest differences are on the [shim page](/docs/sdks/rekognition-shim). On JavaScript, Java, Go or .NET there is no shim: call the REST endpoints (or the [Node SDK](/docs/sdks/node)) and map requests and responses yourself using the table above.

## The runbook

### One call against a scratch collection

Prove credentials, network path and image handling before touching your application. Costs one photo.

### Point a copy of your integration at SightRadar

In a branch, not production. On Python and boto3, swap in the shim. On raw REST, budget for mapping each call.

### Re-index your existing faces

The one unavoidable step. Faceprints are model-specific vectors and are not portable between engines, so no provider can import another's. Re-run indexing over the source images with [batch](/docs/guides/batch-and-webhooks) at the batch rate.

### Dual-write, then compare on live traffic

Index into both systems and send each search to both. Compare ranked photo ids, not raw scores; the scales differ. Ranking agreement is the signal.

### Re-calibrate your threshold on your own data

Do not carry the Rekognition number across. Follow [choosing a threshold](/docs/guides/thresholds). This is the step teams skip and then blame on accuracy.

### Cut over reads, keep the old collection

Rollback stays a config change until you delete the old data.

## Questions teams ask

No, and neither can anyone else. An embedding is a numeric vector produced by one specific model, so another engine's vectors are not meaningful in it. Every provider-to-provider face migration requires re-indexing from source images.

The scale is converted for you (0 to 100 becomes 0 to 1); the right operating point is model-specific and must be re-derived from your own data. Treat a carried-over threshold as a starting guess, never a setting.

Yes, and it is the recommended path. Index into both, search both, compare rankings, cut over when satisfied.

None of the three. Email sign-up plus an API key, no default TPS ceiling to raise by ticket, no approval gate on the recognition operations.

Side-by-side before and after code is on the [migration page](/migrate).