Return to Answer

Two issues really exist:

1. Backwards Compatibility
2. Analytics Redux

Backwards Compatibility

There is a series of upgrade scripts, procedures, and steps in order to upgrade ECM 2.2 to EXM 3.0. I will edit with link to the Upgrade Doc.

However, as of EXM 3.1, backwards compatibility to utilize ECM links, clicks, opens, and bounces was removed. Along with it, reliance on any of the old AutomationStates table.

The real issue is that the links created out of ECM contain ec_as and ec_camp. These correspond to Automation State and Campaign Id.

In EXM, those were removed and now ec_message_id and ec_contact_id.

Well, if you have access to the old Analytics database from 7.x, you can derive a Membership Profile username. But, EXM utilizes xDB contacts. The upgrade scripts creates user accounts in xDB, but the identifier is domain\username and OOTB EXM wants to use email address as primary identifier. So, without close consideration paid attention to, it's possible to have two Experience Profile accounts for the same person, but different identifiers which causes a host of issues.

So, with EXM 3.3, there's no way to get an xDB Contact from the ec_as query param without heavy reverse engineering.

Similarly, you can use the AutomationStates table and Automation table to derive the email message ID.

Knowing that, you can create pipeline processors for <emailOpen>, <handleBounce>, and <redirectUrl> to massage the params and find the contact I'd and message id. But again, you have to build the backwards compatibility.

Lastly, ECM OOTB utilizes the modules_shell site and a ASPX to handle RegiaterEmailOpen. In EXM, this page doesn't exist, and instead moved to a handler (ASHX) that lives in /sitecore. So we had to rebuild the old page functionality but refactor it for EXM and xDB.

Analytics Redux

In EXM 3.3, the entire Message Statistics collection was refactored making any analytics collection from EXM 3.2 invalid. Sitecore did provide some scripts but after repeated tests, found it still didn't upgrade/migrate everything. The client we were working with decided they didn't care about the analytics as much as they cared about the links working.

SUMMARY

We were contracted by a client doing just that to rebuild the backwards compatibility from ECM to EXM 3.3 It was not an easy lift, and resulted in a number of Support tickets. EXM 3.4 will be coming out sometime in the near future which will support Sitecore 8.2, and I've been told that it's a pretty light weight upgrade from EXM 3.3.

Therefore, if coming from ECM 2.2, and going to EXM 3.3, I advocate working with a Sitecore partner to really hone in on what matters most and figuring out a path.

That's about as much advice as I can give.

Two issues really exist:

1. Backwards Compatibility
2. Analytics Redux

Backwards Compatibility

There is a series of upgrade scripts, procedures, and steps in order to upgrade ECM 2.2 to EXM 3.0. I will edit with link to the Upgrade Doc.

However, as of EXM 3.1, backwards compatibility to utilize ECM links, clicks, opens, and bounces was removed. Along with it, reliance on any of the old AutomationStates table.

The real issue is that the links created out of ECM contain ec_as and ec_camp. These correspond to Automation State and Campaign Id.

In EXM, those were removed and now ec_message_id and ec_contact_id.

Well, if you have access to the old Analytics database from 7.x, you can derive a Membership Profile username. But, EXM utilizes xDB contacts. The upgrade scripts creates user accounts in xDB, but the identifier is domain\username and OOTB EXM wants to use email address as primary identifier. So, without close consideration paid attention to, it's possible to have two Experience Profile accounts for the same person, but different identifiers which causes a host of issues.

So, with EXM 3.3, there's no way to get an xDB Contact from the ec_as query param without heavy reverse engineering.

Similarly, you can use the AutomationStates table and Automation table to derive the email message ID.

Knowing that, you can create pipeline processors for <emailOpen>, <handleBounce>, and <redirectUrl> to massage the params and find the contact I'd and message id. But again, you have to build the backwards compatibility.

Lastly, ECM OOTB utilizes the modules_shell site and a ASPX to handle RegiaterEmailOpen. In EXM, this page doesn't exist, and instead moved to a handler (ASHX) that lives in /sitecore. So we had to rebuild the old page functionality but refactor it for EXM and xDB.

Analytics Redux

EDIT: Anthony describes the story around analytics way better than I. Refer to his response.

SUMMARY

We were contracted by a client doing just that to rebuild the backwards compatibility from ECM to EXM 3.3 It was not an easy lift, and resulted in a number of Support tickets. EXM 3.4 will be coming out sometime in the near future which will support Sitecore 8.2, and I've been told that it's a pretty light weight upgrade from EXM 3.3.

Therefore, if coming from ECM 2.2, and going to EXM 3.3, I advocate working with a Sitecore partner to really hone in on what matters most and figuring out a path.

That's about as much advice as I can give.

Two issues really exist:

1. Backwards Compatibility
2. Analytics Redux

Backwards Compatibility

There is a series of upgrade scripts, procedures, and steps in order to upgrade ECM 2.2 to EXM 3.0. I will edit with link to the Upgrade Doc.

However, as of EXM 3.1, backwards compatibility to utilize ECM links, clicks, opens, and bounces was removed. Along with it, reliance on any of the old AutomationStates table.

The real issue is that the links created out of ECM contain ec_as and ec_camp. These correspond to Automation State and Campaign Id.

In EXM, those were removed and now ec_message_id and ec_contact_id.

Well, if you have access to the old Analytics database from 7.x, you can derive a Membership Profile username. But, EXM utilizes xDB contacts. The upgrade scripts creates user accounts in xDB, but the identifier is domain\username and OOTB EXM wants to use email address as primary identifier. So, without close consideration paid attention to, it's possible to have two Experience Profile accounts for the same person, but different identifiers which causes a host of issues.

So, with EXM 3.3, there's no way to get an xDB Contact from the ec_as query param without major reverse engineering.

Analytics Redux

In EXM 3.3, the entire analytics collection was refactored making any analytics collection from EXM 3.2 invalid. Sitecore did provide some scripts but after repeated tests, found it still didn't upgrade/migrate everything.

SUMMARY

We were contracted by a client doing just that to rebuild the backwards compatibility from ECM to EXM 3.3 It was not an easy lift, and resulted in a number of Support tickets. EXM 3.4 will be coming out sometime in the near future which will support Sitecore 8.2, and I've been told that it's a pretty light weight upgrade from EXM 3.3.

Therefore, if coming from ECM 2.2, and going to EXM 3.3, I advocate working with a Sitecore partner to really hone in on what matters most and figuring out a path.

That's about as much advice as I can give.

Two issues really exist:

1. Backwards Compatibility
2. Analytics Redux

Backwards Compatibility

There is a series of upgrade scripts, procedures, and steps in order to upgrade ECM 2.2 to EXM 3.0. I will edit with link to the Upgrade Doc.

However, as of EXM 3.1, backwards compatibility to utilize ECM links, clicks, opens, and bounces was removed. Along with it, reliance on any of the old AutomationStates table.

The real issue is that the links created out of ECM contain ec_as and ec_camp. These correspond to Automation State and Campaign Id.

In EXM, those were removed and now ec_message_id and ec_contact_id.

Well, if you have access to the old Analytics database from 7.x, you can derive a Membership Profile username. But, EXM utilizes xDB contacts. The upgrade scripts creates user accounts in xDB, but the identifier is domain\username and OOTB EXM wants to use email address as primary identifier. So, without close consideration paid attention to, it's possible to have two Experience Profile accounts for the same person, but different identifiers which causes a host of issues.

So, with EXM 3.3, there's no way to get an xDB Contact from the ec_as query param without heavy reverse engineering.

Similarly, you can use the AutomationStates table and Automation table to derive the email message ID.

Knowing that, you can create pipeline processors for <emailOpen>, <handleBounce>, and <redirectUrl> to massage the params and find the contact I'd and message id. But again, you have to build the backwards compatibility.

Lastly, ECM OOTB utilizes the modules_shell site and a ASPX to handle RegiaterEmailOpen. In EXM, this page doesn't exist, and instead moved to a handler (ASHX) that lives in /sitecore. So we had to rebuild the old page functionality but refactor it for EXM and xDB.

Analytics Redux

In EXM 3.3, the entire Message Statistics collection was refactored making any analytics collection from EXM 3.2 invalid. Sitecore did provide some scripts but after repeated tests, found it still didn't upgrade/migrate everything. The client we were working with decided they didn't care about the analytics as much as they cared about the links working.

SUMMARY

We were contracted by a client doing just that to rebuild the backwards compatibility from ECM to EXM 3.3 It was not an easy lift, and resulted in a number of Support tickets. EXM 3.4 will be coming out sometime in the near future which will support Sitecore 8.2, and I've been told that it's a pretty light weight upgrade from EXM 3.3.

Therefore, if coming from ECM 2.2, and going to EXM 3.3, I advocate working with a Sitecore partner to really hone in on what matters most and figuring out a path.

That's about as much advice as I can give.

Two issues really exist:

1. Backwards Compatibility
2. Analytics Redux

Backwards Compatibility

There is a series of upgrade scripts, procedures, and steps in order to upgrade ECM 2.2 to EXM 3.0. I will edit with link to the Upgrade Doc.

However, as of EXM 3.1, backwards compatibility to utilize ECM links, clicks, opens, and bounces was removed. Along with it, reliance on any of the old AutomationStates table.

The real issue is that the links created out of ECM contain ec_as and ec_camp. These correspond to Automation State and Campaign Id.

In EXM, those were removed and now ec_message_id and ec_contact_id.

Well, if you have access to the old Analytics database from 7.x, you can derive a Membership Profile username. But, EXM utilizes xDB contacts. The upgrade scripts creates user accounts in xDB, but the identifier is domain\username and OOTB EXM wants to use email address as primary identifier. So, without close consideration paid attention to, it's possible to have two Experience Profile accounts for the same person, but different identifiers which causes a host of issues.

So, with EXM 3.3, there's no way to get an xDB Contact from the ec_as query param without major reverse engineering.

Analytics Redux

In EXM 3.3, the entire analytics collection was refactored making any analytics collection from EXM 3.2 invalid. Sitecore did provide some scripts but after repeated tests, found it still didn't upgrade/migrate everything.

SUMMARY

We were contracted by a client doing just that to rebuild the backwards compatibility from ECM to EXM 3.3 It was not an easy lift, and resulted in a number of Support tickets. EXM 3.4 will be coming out sometime in the near future which will support Sitecore 8.2, and I've been told that it's a pretty light weight upgrade

Therefore, if coming from ECM 2.2, and going to EXM 3.3, I advocate working with a Sitecore partner to really hone in on what matters most and figuring out a path.

That's about as much advice as I can give.

Two issues really exist:

1. Backwards Compatibility
2. Analytics Redux

Backwards Compatibility

There is a series of upgrade scripts, procedures, and steps in order to upgrade ECM 2.2 to EXM 3.0. I will edit with link to the Upgrade Doc.

However, as of EXM 3.1, backwards compatibility to utilize ECM links, clicks, opens, and bounces was removed. Along with it, reliance on any of the old AutomationStates table.

The real issue is that the links created out of ECM contain ec_as and ec_camp. These correspond to Automation State and Campaign Id.

In EXM, those were removed and now ec_message_id and ec_contact_id.

Well, if you have access to the old Analytics database from 7.x, you can derive a Membership Profile username. But, EXM utilizes xDB contacts. The upgrade scripts creates user accounts in xDB, but the identifier is domain\username and OOTB EXM wants to use email address as primary identifier. So, without close consideration paid attention to, it's possible to have two Experience Profile accounts for the same person, but different identifiers which causes a host of issues.

So, with EXM 3.3, there's no way to get an xDB Contact from the ec_as query param without major reverse engineering.

Analytics Redux

In EXM 3.3, the entire analytics collection was refactored making any analytics collection from EXM 3.2 invalid. Sitecore did provide some scripts but after repeated tests, found it still didn't upgrade/migrate everything.

SUMMARY

We were contracted by a client doing just that to rebuild the backwards compatibility from ECM to EXM 3.3 It was not an easy lift, and resulted in a number of Support tickets. EXM 3.4 will be coming out sometime in the near future which will support Sitecore 8.2, and I've been told that it's a pretty light weight upgrade from EXM 3.3.

Therefore, if coming from ECM 2.2, and going to EXM 3.3, I advocate working with a Sitecore partner to really hone in on what matters most and figuring out a path.

That's about as much advice as I can give.