Migration Scenarios


Describes migration scenarios, key terminology and workflow. The the most common use case for Native API partners is Scenario 1.


There are currently 3 well-defined migration scenarios for Native API partners who wish to move ahead and migrate their accounts to DSP and the Yahoo unified ad campaign platform.

Scenario 1

Scenario 1 is the preferred migration strategy and most common use case for API partners and developers. This recommended migration path is for new campaigns to be created and managed in DSP while the old campaigns will continue to be managed via Native API until they expire.

Typically, this process involves a one-time migration of an account from Yahoo Native to a corresponding Yahoo DSP account after which the DSP account becomes the source of truth.


For Scenario 1 migrations, Native will not block new campaign creation in Native. This provides both partners and solution engineering teams with greater flexibility in handling non-typical or incremental migrations.

All migrated partners can continue to use the Native APIs to maintain existing (no new) campaigns until they expire (or they hit the API migration cutoff date) and use the DSP APIs for all new campaigns and reporting.

Scenario 2

Scenario 2 is recommended for high-value, premium Dynamic Product Ad (DPA) advertisers with large product catalogs. If you’re an advertiser with a large product catalog, your existing product catalogs will be made available via the DSP APIs. The product catalog id namespace will also be maintained.

Reach out to the the partner solutions team when moving ahead to implement this scenario at solutionsengineering@yahooinc.com.


Post-Scenario 2 migration, Native APIs will prevent writes. Otherwise campaigns originating from the DSP migration process could be updated via Native APIs - thus, causing data consistency issues. Note also that Packages are essential for DPA and Scenario 2 migrations.

Note that advertisers can now buy DPA using the core DPA Traffic APIs on the DSP platform. All the DPA functionalities on the UI are also available through the external Traffic APIs, including DPA pixel rules, product feed management, product set management, line operations, targeting operations, and creative operations. This enables DPA clients to manage a large number of campaigns more easily and more efficiently. Refer to the overview of the Native DPA APIs for more information.

Scenario 3

Scenario 3 involves programmatically reading from Native APIs and writing to DSP. The Yahoo engineering team has provided a robust collection of Java code examples that demonstrate how to do this. The code snippets also show the object mapping between both platforms.

Refer to Java sample code for reading from Native and writing to DSP, which you can download.

Terminology At a Glance




The one-time copying of account data from Native into DSP.

Source account

The Native account that is being migrated into DSP. Once successfully migrated, this account will be deactivated. Note that only managed accounts are supported.

Destination account

The DSP account that contains the migrated Native account data. This is now considered the source of truth.

Migration Workflow

For Scenario 1, the migration workflow from Native to DSP involves the following 3 steps:

Step 1. Provision accounts and users

  1. You create a Yahoo DSP destination account and a Native source account, which you’ll use to migrate into DSP. Note that you’ll need to authenticate with OAuth 2.0 for your DSP account. Doing so requires a separate token from the one used to authenticate on Native. Refer to the DSP Authentication Guide for more information.

  2. You verify the account mapping.

Step 2. Import source account into DSP

  1. DSP fetches the source account data from Native via a Bulk download.

  2. DSP performs the domain model mapping.

  3. DSP imports demand into DSP and outputs a summary. Campaigns are imported with a status of OFF to prevent them from going live and competing with source campaigns.

  4. Demand is automatically replicated to Native upon creation in DSP.

  5. Native ensures that backend controls that are applied to source entities are also applied to other entities.

Step 3. Account switch-over

  1. You incrementally turn ON the destination campaigns in DSP.

  2. You incrementally turn OFF the source campaigns in Native.