Migrate from Pinpoint-backed features

Amazon Pinpoint will reach end of support on October 30, 2026. The Pinpoint-backed features in the Amplify libraries are in maintenance mode until that date and will stop functioning afterward. This guide walks you through migrating each affected capability to its replacement.

The affected capabilities are:

• Analytics: user identification, event and metrics recording backed by Pinpoint
• Push Notifications: device registration, campaigns, and message handling backed by Pinpoint

Migration paths at a glance

Migrate user identification and push notifications to Amazon Connect Customer Profiles

The Amplify libraries now support Amazon Connect Customer Profiles as the backend for identifying users and registering devices for push notifications. The migration has two parts: deploy the new backend, then update your app code. You do not need to move any data to get started. As your users sign in and open your app, their profiles are created in Customer Profiles and their devices are registered automatically.

1. Add the notifications backend

Add the notifications resource to your Amplify backend. This provisions an Amazon Connect Customer Profiles domain and the API your app communicates with.

npm add @aws-amplify/backend-notifications

import { defineBackend } from '@aws-amplify/backend';
import { defineNotifications } from '@aws-amplify/backend-notifications';
import { auth } from './auth/resource';

defineBackend({
  auth,
  notifications: defineNotifications()
});

Deploy your backend. The generated amplify_outputs.json now contains a notifications section that the Amplify libraries read automatically. No manual client configuration is required.

2. Update your application code

The Customer Profiles provider exposes three APIs: identifyUser to associate profile attributes with the current user, registerDevice to register the device push token, and removeDevice to deregister it (for example, on sign-out).

Update your identifyUser calls to the new provider. User attributes now live on the profile as customAttributes, and device details are handled by the library.

// Before (Pinpoint provider)
import { identifyUser } from 'aws-amplify/push-notifications';

await identifyUser({
  userId: 'user-123',
  userProfile: { email: 'user@example.com' },
  options: {
    userAttributes: { interests: ['food'] }
  }
});

// After (Customer Profiles provider)
import { identifyUser } from 'aws-amplify/push-notifications/customer-profiles';

await identifyUser({
  userProfile: {
    email: 'user@example.com',
    customAttributes: { interests: 'food' }
  }
});

A few things to note:

• You no longer pass a userId. The backend derives the caller's identity from the request, for both signed-in and guest users.
• Device registration requires no code change beyond switching the import for initializePushNotifications. The token registration that previously updated a Pinpoint endpoint now registers a device with Customer Profiles. You can also call registerDevice directly if you manage tokens yourself.
• Call removeDevice on sign-out if you want the device to stop receiving push notifications for that user.

The Amplify Swift, Android, and Flutter libraries expose the same three APIs through their Connect client packages.

3. Let your user profiles repopulate

Once the updated app version is released, profiles build back up on their own: each time a user signs in and your app calls identifyUser, their profile is created or updated in Customer Profiles, and their device is registered the next time the app receives a push token. Ship the backend change first, then the app update, and your active users carry over as they use the app.

Migrate analytics event recording

If you use Pinpoint-backed Analytics to record events, migrate to streaming events with Amazon Kinesis Data Streams or Amazon Data Firehose. Both are supported today in the Amplify library:

• Stream analytics data with Amazon Kinesis
• Store analytics data with Amazon Data Firehose

1. Update your event recording calls

Each streaming provider exposes record and flushEvents from its own subpath of aws-amplify/analytics. Switch the import to the provider you chose, then pass the destination stream alongside your event payload. The event name, attributes, and metrics you previously passed as separate fields become the data blob written to the stream.

// Before (Pinpoint provider)
import { record } from 'aws-amplify/analytics';

record({
  name: 'albumVisit',
  attributes: { genre: 'jazz' },
  metrics: { minutesListened: 30 }
});

// After (Kinesis provider)
import { record } from 'aws-amplify/analytics/kinesis';

record({
  streamName: 'myKinesisStream',
  partitionKey: 'myPartitionKey',
  data: {
    name: 'albumVisit',
    genre: 'jazz',
    minutesListened: 30
  }
});

To send records to a Firehose delivery stream instead, import from aws-amplify/analytics/kinesis-firehose and pass the delivery stream as streamName. Firehose records do not take a partitionKey.

Records are buffered and delivered periodically, so keep any existing flushEvents calls and update their import to match the provider you now record with.

import { flushEvents } from 'aws-amplify/analytics/kinesis';

flushEvents();

2. Update automatic tracking

configureAutoTrack is available on both streaming providers and keeps the same session, pageView, and event tracking types. Because each automatically tracked event needs a destination, add the stream coordinates to options.

// Before (Pinpoint provider)
import { configureAutoTrack } from 'aws-amplify/analytics';

configureAutoTrack({
  enable: true,
  type: 'session'
});

// After (Kinesis provider)
import { configureAutoTrack } from 'aws-amplify/analytics/kinesis';

configureAutoTrack({
  enable: true,
  type: 'session',
  options: {
    streamName: 'myKinesisStream',
    partitionKey: 'myPartitionKey'
  }
});

The streaming providers record events only; they do not provide an identifyUser API. Move your Analytics identifyUser calls to Amazon Connect Customer Profiles as described in Migrate user identification and push notifications.

Moving existing Pinpoint endpoint data

For most applications, no bulk data migration is needed: profiles repopulate organically as described above, and inactive endpoints age out with your Pinpoint project. If you need to carry over attributes for users before they next open your app, you can export your Pinpoint endpoints and write the relevant attributes to Customer Profiles using the Amazon Connect Customer Profiles APIs. Detailed guidance for this workflow will be added to this page.