Home AppMeasurement Web SDK · Migration Guide Created by Amit G Dusane

Migration › Migrate identity (ECID)

Step 07 of 13
54% complete

Migrate identity (ECID)

Every visitor Adobe has ever seen carries an identity, the ECID, and your site has been storing it in a cookie for years. The risk in this migration isn't losing data; it's losing continuity. If the Web SDK starts minting fresh IDs, every returning visitor looks brand-new overnight. One checkbox prevents this: it tells the Web SDK to read the identity already in the visitor's cookie and keep using it, so the person who bought from you last week is still the same person this week. It is the smallest action in the whole migration with the largest downside if missed.
What to do
1
Where (Web SDK extension config) › Identity
Do Tick "Migrate ECID from VisitorAPI to the web SDK." Save. Requires the same Org ID and same domain[7] as the old Visitor API.
Without ID migration unique visitors cutover uniques spike everyone looks new With idMigrationEnabled cutover continuous ECID carried across
Skip the one checkbox and returning visitors get fresh IDs, unique visitors spike at cutover. With idMigrationEnabled, the ECID rides across and the line stays smooth.
⚠ Common mistake, the story everyone learns the hard way

Teams treat this checkbox as obvious and skip validating it. Three weeks after go-live, unique visitors spike and returning-visitor trends collapse. The implementation was technically correct, identity continuity was simply never confirmed.

Reality check

It defaults on and needs no Client Care ticket, but "defaults on" is not "verified on." In the Debugger, confirm a returning visitor's ECID actually matches their old AMCV_ cookie value.

✓ You should see

The checkbox enabled, and later, in the Debugger, a returning visitor's ECID equal to their pre-migration value.