You’re reading this because you either are evaluating MS Dynamics or have already made the decision to migrate to this CRM platform. We at Serena Software made this decision to migrate about 1 year ago from SFDC and this is a recap of everything I have learned.
I am the marketing ops manager here at Serena and am the primary Marketo admin, responsible for architecting our programs infrastructure and integration with the CRM system. Although this is a lengthy document you will benefit from reading it. We made several mistakes along the way, so hopefully by sharing our experiences you can avoid repeating them.
This document is organized along the lines of a typical business app sales lifecycle. I have merged or modified some stages to keep it as concise as possible.
- Research & Discovery
- Specifying Requirements
- Development & Testing
- Post Go Live Activities
Before we get into these details, here are some general thoughts on what you need to be successful.
· Executive buy-in and support – It’s critical that the C-level team sees your CRM system as a value-add which can give you a competitive advantage, rather than a commodity and a line item on a budget that can be cut by switching to another vendor.
· Adequate timeline & budget – we implemented SFDC successfully in 2006 with a 9 month project and it was strictly for sales. We attempted to migrate to Dynamics, which is used by support and sales, in less than 6 months with a smaller consulting team than we had in 2006. This ties in closely with the first point. If it’s all about lower cost, you are sure to be lost…
· Committed team leads from all functional areas – What makes a migration so challenging is that we all still have our regular jobs to execute, but you need a core team of support, marketing, sales, finance personnel, and anyone else who will touch the CRM system to be intimately involved both pre and post go live.
· Continued focus after go live – Go live is not the end of the project. In many ways your work is just beginning. You will need to remain vigilant and continue to test and monitor all aspects of your operation.
Part 1: Research & Discovery
Key Functionality Differences between Dynamics and SFDC
This list is by no means comprehensive but it’s critical that anyone migrating from SFDC to Dynamics know about them and plan accordingly. I should be clear that we are on Dynamics 2011 and at the time of this posting Dynamics 2013 is the most current version. I cannot speak to the differences in capabilities except on the lead to contact conversion process which I detail later.
· Dynamics’ Integration with Office Benefits
The integration with Office has at least a couple benefits that can improve productivity.
- Outlook integration – we’re having stability issues (random crashes and other performance problems) but in theory this is really convenient because we all work in Outlook all the time and Dynamics is just a click away.
- Dynamic Excel spreadsheets – This is something SFDC can’t do. You can create a report in Dynamics and rather than export it as a static spreadsheet you can send other Dynamics users (your coworkers) a file that can pull in real-time data from Dynamics when they open it. Quite powerful when you’re dealing with tracking reports and such.
· Dynamics has no campaign members object
This is the object in SFDC that tracks campaign responses. Dynamics offers the concept of “lists” instead. It is insufficient. In our campaign tracking model for example, if a prospect responds to 4 campaigns we have 1 lead in the CRM system with 4 campaigns listed in the Campaign History section of the lead record (member of 4 campaigns). If you have been using SFDC’s campaign members object to track campaign responses in this fashion, you will need to build a custom object in Dynamics.
The only problem I see with our custom campaign members object so far is on the reporting side. I can’t build any views against it (because it is custom?) nor can I build a clean report like I could in SFDC that shows all respondents to a campaign. I can do it but I have to put separate lead and contact fields such as first name, last name, address, etc. if I want to see everyone in a single file. Really messy obviously. Perhaps if you specify this as a requirement up front it can be made to work just like SFDC’s campaign members report. If you end up like us, you might be better off having separate Campaign Members – Leads and Campaign Members – Contacts reports with the same columns and merging them together in Excel if you need to share these lists with coworkers.
· Dynamics 2011 has inadequate lead qualification to contact functionality (lead conversion in SFDC terms)
Dynamics’ standard lead qualification process (in Dynamics 2011) makes it impossible for users to add a lead to an existing account, or merge a lead into an existing contact if a match exists. Every qualification will result in a brand new contact and account, even if both already exist. I was given a demo of how a sales rep could correctly merge a lead into an existing contact/account in Dynamics 2013 but it is not built into the standard lead qualify to contact process. Users have to take a completely separate route to do it – therefore they won’t. Build a custom workflow that emulates SFDC’s lead conversion process. Step 1 – look for a matching account and allow the user to confirm. Step 2 – look for matching contacts in the account if qualifying lead into an existing account.
· Dynamics reporting tool lags behind SFDC’s
This is a common theme with Dynamics. It may do what SFDC does, but less elegantly – more clicks, etc. With reports, non-admin users in Dynamics get to use what’s called a “Report Wizard”. It is incredibly clunky compared to SFDC’s and here are some of its shortcomings we’ve discovered thus far. We’re just getting into report and dashboard building so I may add to this in the future.
- 2 table joins max. There are no prepackaged joins like in SFDC (Campaigns with Leads for example). You have to create the join from scratch and then apply your filters and columns. You are limited to 2 tables (objects).
- Can’t provide a true summary of results – if you want to see how many campaign responses you’ve collected in the past week for example and just see the number of responses for each campaign, you can’t “collapse” the results (leads/contacts in this case) like you can in SFDC.
As you can see, there are some substantial differences in how these CRM systems are designed so ideally you should partner with consultants that are intimately familiar with both. I don’t know if there are consultants out there who have mastered both platforms and know Marketo (ours were Dynamics experts only) but it will increase your chances of success if you can find one.
Part 2: Specifying Requirements
· Be Detailed and Be Thorough
This will be a tedious process but you cannot succeed if you can’t articulate in detail what you want delivered out of this implementation. You should take screenshots, diagram workflows, whatever it takes to convey how your processes work, or how you want to change them. Same with reports and dashboards – show the underlying filters, not just the end results. There’s no guarantee the consultants will act on these documents, but in a worst case scenario your legal team can use them to prove whether the consultants have delivered on what you asked for.
Take a complete inventory of your existing processes and workflows – that exist in Marketo or SFDC. As part of this exercise we realized there were many workflows we had in SFDC that could be handled by Marketo. Whenever possible, take control of your destiny – build the workflow in Marketo.
Part 3: Development & Testing
· Clean up your CRM/support databases
This is a great time to evaluate which lead and contact records are stale and can be left behind (deleted) and use 3rd party tools to merge duplicates. We used Ringlead to merge duplicates in SFDC. To try and gauge how stale a record is, use fields like last campaign response date, last modified date (by sales users, not the generic modified by field), opportunity date, and activity date. Work with sales to come to an agreement on how far back in time you want to go on these attributes – 1 year, etc.
· Do NOT upload duplicate records into Dynamics
Much of our deduping cleanup work in SFDC was for naught because to make our deadline, our implementation team uploaded contacts from our support database and SFDC into Dynamics without merging them beforehand. About 15% of our contacts database is now duplicates. 3 months later, IT and the consultants are still trying to work through the technical challenges associated with merging these records.
· Have Marketo professional services clone your existing Marketo environment.
Unfortunately, you cannot unhook your existing Marketo instance from SFDC or whatever CRM it is connected to, and hook it up to Dynamics. You must have a new Marketo environment provisioned. Have Marketo pro services clone your existing environment and then you can modify it to work with Dynamics, or whatever CRM you are migrating to. While still a tedious undertaking (smart lists and flow steps that have touchpoints to CRM will all need to be replaced), this is far better than having to rebuild a completely new environment from scratch.
· Don’t use the Marketo program import tool, except for one-offs after you have your new cloned environment.
Why? This import tool generates new landing page and email templates every time you import a new program with email or landing page assets, even if the template already exists in your new environment.
If you have to import individual programs after you have 2 environments and you are in your transition period, you need to manually clone/reclone landing pages or completely rebuild emails in the new environment to get the right templates in place on your content assets and delete the unwanted templates you created via the import process.
· Create a custom lead to contact conversion workflow in Dynamics
Dynamics’ standard lead conversion process (they call it qualification) in Dynamics 2011 makes it impossible for users to add a lead to an existing account, or merge a lead into an existing contact if a match exists. I saw a demo of how a sales rep could accomplish this in Dynamics 2013 but it is not built into the standard lead to contact qualification process. Users have to go out of their way to do it – therefore they won’t.
Build a custom workflow that emulates SFDC’s lead conversion process. Step 1 – look for a matching account and allow the user to confirm. Step 2 – look for matching contacts in the account if qualifying lead into an existing account.
Warning – make sure this workflow (dialogue) correctly communicates back to Marketo that this is a lead qualification taking place. Otherwise it will create a duplicate record in the Marketo database. We identified this issue 3 weeks ago and at the time of this posting, Microsoft and Marketo technicians are still attempting to solve this problem for us.
· Create a dedicated Dynamics user account for the Marketo-Dynamics data sync.
Why? Marketo does not pull back Dynamics records created by or recognize updates to existing Dynamics records made by the user account designated for the data sync, because it would create a circular reference (endless loop of updates between Marketo and CRM database). The worst case scenario is that you connect your new Marketo instance to Dynamics and then upload leads and contacts into Dynamics with the same user account used for the data sync. You would end up with an entire Dynamics database that cannot be pulled back into Marketo and you would need to start over.
Here are some other important details to note on this Dynamics user account
- Make sure this designated Dynamics has an email address associated with it. Unlike SFDC user accounts, Dynamics accounts do not require an email. Marketo does require it though, so that’s why it’s needed.
- Make sure the password is set to NEVER EXPIRE. If you don’t do this, the password expires in 90 days and the data sync will fail. Marketo keeps a log of the failed transactions and will backfill them when the sync is restored but this is clearly very disruptive potentially to the business.
· Do you use single sign-on for Outlook, Dynamics, and other network-hosted apps?
Marketo will not be able to authenticate your Dynamics user account login credentials and you will be unable to initiate the Marketo-Dynamics sync.
Get your network admin, Marketo pro services and your consultants collaborating to figure out how to get past this single sign-in block. We lost 2-3 weeks waiting for them to figure it out.
· Prepare Webex, or other webinar hosting service programs, in advance in your new Marketo environment.
During your transition period you will probably have live webinars that you are running in your outgoing environment, but will need to wrap up in your new environment. To make this transition seamlessly, you can connect one Webex event (or other vendor event) to the same Marketo program in 2 different environments. Since you can only connect a Webex event to a Marketo program BEFORE there are any members in it, you should establish the connection right when you get your new environment for webinars that are in progress (occurring during your transition period). You will eventually need to import lists into this program in the new environment and specify who has been invited, registered, etc. Establishing the connection before you do any of these list imports eliminates this problem.
· Do NOT import lead lists into your new Marketo environment until the Marketo-Dynamics data sync is established.
Why? If you try to get a head start, by let’s say, importing your unsubscribe list in advance, Marketo will create duplicate records when the Marketo-Dynamics sync is initiated. This is the one occasion where Marketo does not recognize an existing email as a unique record. You want your new Marketo environment to have ZERO leads when you initiate the Marketo-Dynamics data sync.
· Work with Marketo pro services and your IT department to make sure your landing page and image URLs are the same when you switch from your old environment to your new environment.
At the time of this posting, Marketo is working on a more automated and elegant solution, but in the meantime, collaborate with these knowledge experts and you will not have to manually create redirects for every URL you need to manage.
· Do NOT create too many user roles in Dynamics and create an overly “closed” system
Instead of having a few user roles, with substantial rights and permissions, our team decided to take a very fragmented approach, creating very specific user roles (Marketo Sales Insight for example) with very limited rights. Users then need to have a “bundle” of roles in order to have all the rights and permissions they need. It’s a nightmare to manage and we’re still dealing with people being unable to see each other’s reports, etc. 3 months in.
· Beware of Date/Time vs. Date Only field types if you have date fields mapped to corresponding fields in Dynamics.
Dynamics does not have the concept of a Date field. They only have "Date + Time". If you migrate an existing Date Only field from your old Marketo instance it will be mapped to a Date + Time field in Dynamics. If you create a new Date + Time field in Dynamics and pull it back to Marketo, Dynamics gives you the option of how you want to display it in Dynamics = Date only or Date + Time. Your selection here will determine the field TYPE pulled back into Marketo. In other words, if you tell Dynamics to display it as a date, it, Marketo will create it as a Date Only field in Marketo. If you tell Dynamics to display it as Date/Time in Dynamics, it becomes a Date/Time field in Marketo.
This decision can have impacts if your date values ever get out of sync on this field between the 2 systems. In our case, a single text field being too short in Dynamics and a plugin failing to be turned on led to this outcome. Dynamics contacts are more problematic to fix because Marketo does not overwrite the Dynamics contact record if it finds a value that does not match what it expects to see (the old value on the Marketo record). There is only one way to get these records back in sync if you go with a Date Only field in Marketo:
1) Delete the date values in Dynamics via a spreadsheet upload into Dynamics (warning - it will take a LONG time)
2) Wait for Marketo to pull back the null value on all records
3) Reimport the correct date values back into Marketo
If you went with a Date/Time field type in both databases, you can simply do the following:
1) Upload the correct date values into Dynamics. Use 12 am as your time if you do not have one.
Note - all of this is for Dynamics contacts. Marketo can overwrite Dynamics leads data when records are out of sync so you can import directly into Marketo if you wan to fix leads in Dynamics on your own.
Also Note - the time zone setting of the Dynamics user account used for the upload into Dynamics does matter so you will need to test. In our case, a user account with a PST setting led to an exact time match when pulled back to Marketo, and a GMT setting led to an 8 hour difference.
Part 4: Post Go Live Activities
· Remain vigilant! Monitor and Test
Create views and reports in both Marketo and Dynamics to ensure lead pass-thru and other key functions are working properly. As an example, I have a leads view in Dynamics that I check daily to see leads that have been created or updated today. If it is empty it means there’s Marketo-Dynamics sync has been disabled.
· Do NOT trust data values of fields that originated in your old CRM system after you have made your CRM system read only.
We made our SFDC instance read only a couple weeks before we were able to go live in our new Marketo-Dynamics environment. During this period, Marketo was able to add existing SFDC leads/contacts as campaign members in the read only SFDC environment. However it wasn’t able to update fields on the lead or contact record, like custom fields we have such as “First Campaign Name” or “Last Campaign Response Date”. There was a strange disconnect where the correct new value was appearing on the lead record in Marketo, but if you ran a smart list, Marketo would display the outdated SFDC value.
Part 5 - Addendums
March 2014 - I have another painful lesson to pass along. We migrated from Dynamics 2011 to 2013 about 1 month ago. Immediately after the migration we started to see contacts in Dynamics fail to update when they responded to campaigns. About 90% of all contacts were affected and the sync would fail in both directions - update the record in Dynamics and Marketo would fail to pull the update back into the corresponding Marketo record and vice versa. After weeks of MS, Marketo and my IT team investigating logs and testing various theories we discovered the problem.
In Marketo, we have lead and contact dedupelication settings - see screenshot below. Even admins like myself can't see this - only Marketo engineering has access apparently. In any case, for Contacts it must be set to True. Like I said, as an end user you have no visibility to this, but if you migrate to Dynamics 2013 I strongly recommend submitting a support ticket and have someone in engineering verify your settings are correct. You want the Contacts to be set to TRUE. It's a non-factor in Dynamics 2011 but becomes a very big deal in 2013.
I am the marketing ops manager here at Serena and am the primary Marketo admin, responsible for architecting our programs infrastructure and integration with the CRM system. Although this is a lengthy document you will benefit from reading it. We made several mistakes along the way, so hopefully by sharing our experiences you can avoid repeating them.
This document is organized along the lines of a typical business app sales lifecycle. I have merged or modified some stages to keep it as concise as possible.
- Research & Discovery
- Specifying Requirements
- Development & Testing
- Post Go Live Activities
Before we get into these details, here are some general thoughts on what you need to be successful.
· Executive buy-in and support – It’s critical that the C-level team sees your CRM system as a value-add which can give you a competitive advantage, rather than a commodity and a line item on a budget that can be cut by switching to another vendor.
· Adequate timeline & budget – we implemented SFDC successfully in 2006 with a 9 month project and it was strictly for sales. We attempted to migrate to Dynamics, which is used by support and sales, in less than 6 months with a smaller consulting team than we had in 2006. This ties in closely with the first point. If it’s all about lower cost, you are sure to be lost…
· Committed team leads from all functional areas – What makes a migration so challenging is that we all still have our regular jobs to execute, but you need a core team of support, marketing, sales, finance personnel, and anyone else who will touch the CRM system to be intimately involved both pre and post go live.
· Continued focus after go live – Go live is not the end of the project. In many ways your work is just beginning. You will need to remain vigilant and continue to test and monitor all aspects of your operation.
Part 1: Research & Discovery
Key Functionality Differences between Dynamics and SFDC
This list is by no means comprehensive but it’s critical that anyone migrating from SFDC to Dynamics know about them and plan accordingly. I should be clear that we are on Dynamics 2011 and at the time of this posting Dynamics 2013 is the most current version. I cannot speak to the differences in capabilities except on the lead to contact conversion process which I detail later.
· Dynamics’ Integration with Office Benefits
The integration with Office has at least a couple benefits that can improve productivity.
- Outlook integration – we’re having stability issues (random crashes and other performance problems) but in theory this is really convenient because we all work in Outlook all the time and Dynamics is just a click away.
- Dynamic Excel spreadsheets – This is something SFDC can’t do. You can create a report in Dynamics and rather than export it as a static spreadsheet you can send other Dynamics users (your coworkers) a file that can pull in real-time data from Dynamics when they open it. Quite powerful when you’re dealing with tracking reports and such.
· Dynamics has no campaign members object
This is the object in SFDC that tracks campaign responses. Dynamics offers the concept of “lists” instead. It is insufficient. In our campaign tracking model for example, if a prospect responds to 4 campaigns we have 1 lead in the CRM system with 4 campaigns listed in the Campaign History section of the lead record (member of 4 campaigns). If you have been using SFDC’s campaign members object to track campaign responses in this fashion, you will need to build a custom object in Dynamics.
The only problem I see with our custom campaign members object so far is on the reporting side. I can’t build any views against it (because it is custom?) nor can I build a clean report like I could in SFDC that shows all respondents to a campaign. I can do it but I have to put separate lead and contact fields such as first name, last name, address, etc. if I want to see everyone in a single file. Really messy obviously. Perhaps if you specify this as a requirement up front it can be made to work just like SFDC’s campaign members report. If you end up like us, you might be better off having separate Campaign Members – Leads and Campaign Members – Contacts reports with the same columns and merging them together in Excel if you need to share these lists with coworkers.
· Dynamics 2011 has inadequate lead qualification to contact functionality (lead conversion in SFDC terms)
Dynamics’ standard lead qualification process (in Dynamics 2011) makes it impossible for users to add a lead to an existing account, or merge a lead into an existing contact if a match exists. Every qualification will result in a brand new contact and account, even if both already exist. I was given a demo of how a sales rep could correctly merge a lead into an existing contact/account in Dynamics 2013 but it is not built into the standard lead qualify to contact process. Users have to take a completely separate route to do it – therefore they won’t. Build a custom workflow that emulates SFDC’s lead conversion process. Step 1 – look for a matching account and allow the user to confirm. Step 2 – look for matching contacts in the account if qualifying lead into an existing account.
· Dynamics reporting tool lags behind SFDC’s
This is a common theme with Dynamics. It may do what SFDC does, but less elegantly – more clicks, etc. With reports, non-admin users in Dynamics get to use what’s called a “Report Wizard”. It is incredibly clunky compared to SFDC’s and here are some of its shortcomings we’ve discovered thus far. We’re just getting into report and dashboard building so I may add to this in the future.
- 2 table joins max. There are no prepackaged joins like in SFDC (Campaigns with Leads for example). You have to create the join from scratch and then apply your filters and columns. You are limited to 2 tables (objects).
- Can’t provide a true summary of results – if you want to see how many campaign responses you’ve collected in the past week for example and just see the number of responses for each campaign, you can’t “collapse” the results (leads/contacts in this case) like you can in SFDC.
As you can see, there are some substantial differences in how these CRM systems are designed so ideally you should partner with consultants that are intimately familiar with both. I don’t know if there are consultants out there who have mastered both platforms and know Marketo (ours were Dynamics experts only) but it will increase your chances of success if you can find one.
Part 2: Specifying Requirements
· Be Detailed and Be Thorough
This will be a tedious process but you cannot succeed if you can’t articulate in detail what you want delivered out of this implementation. You should take screenshots, diagram workflows, whatever it takes to convey how your processes work, or how you want to change them. Same with reports and dashboards – show the underlying filters, not just the end results. There’s no guarantee the consultants will act on these documents, but in a worst case scenario your legal team can use them to prove whether the consultants have delivered on what you asked for.
Take a complete inventory of your existing processes and workflows – that exist in Marketo or SFDC. As part of this exercise we realized there were many workflows we had in SFDC that could be handled by Marketo. Whenever possible, take control of your destiny – build the workflow in Marketo.
Part 3: Development & Testing
· Clean up your CRM/support databases
This is a great time to evaluate which lead and contact records are stale and can be left behind (deleted) and use 3rd party tools to merge duplicates. We used Ringlead to merge duplicates in SFDC. To try and gauge how stale a record is, use fields like last campaign response date, last modified date (by sales users, not the generic modified by field), opportunity date, and activity date. Work with sales to come to an agreement on how far back in time you want to go on these attributes – 1 year, etc.
· Do NOT upload duplicate records into Dynamics
Much of our deduping cleanup work in SFDC was for naught because to make our deadline, our implementation team uploaded contacts from our support database and SFDC into Dynamics without merging them beforehand. About 15% of our contacts database is now duplicates. 3 months later, IT and the consultants are still trying to work through the technical challenges associated with merging these records.
· Have Marketo professional services clone your existing Marketo environment.
Unfortunately, you cannot unhook your existing Marketo instance from SFDC or whatever CRM it is connected to, and hook it up to Dynamics. You must have a new Marketo environment provisioned. Have Marketo pro services clone your existing environment and then you can modify it to work with Dynamics, or whatever CRM you are migrating to. While still a tedious undertaking (smart lists and flow steps that have touchpoints to CRM will all need to be replaced), this is far better than having to rebuild a completely new environment from scratch.
· Don’t use the Marketo program import tool, except for one-offs after you have your new cloned environment.
Why? This import tool generates new landing page and email templates every time you import a new program with email or landing page assets, even if the template already exists in your new environment.
If you have to import individual programs after you have 2 environments and you are in your transition period, you need to manually clone/reclone landing pages or completely rebuild emails in the new environment to get the right templates in place on your content assets and delete the unwanted templates you created via the import process.
· Create a custom lead to contact conversion workflow in Dynamics
Dynamics’ standard lead conversion process (they call it qualification) in Dynamics 2011 makes it impossible for users to add a lead to an existing account, or merge a lead into an existing contact if a match exists. I saw a demo of how a sales rep could accomplish this in Dynamics 2013 but it is not built into the standard lead to contact qualification process. Users have to go out of their way to do it – therefore they won’t.
Build a custom workflow that emulates SFDC’s lead conversion process. Step 1 – look for a matching account and allow the user to confirm. Step 2 – look for matching contacts in the account if qualifying lead into an existing account.
Warning – make sure this workflow (dialogue) correctly communicates back to Marketo that this is a lead qualification taking place. Otherwise it will create a duplicate record in the Marketo database. We identified this issue 3 weeks ago and at the time of this posting, Microsoft and Marketo technicians are still attempting to solve this problem for us.
· Create a dedicated Dynamics user account for the Marketo-Dynamics data sync.
Why? Marketo does not pull back Dynamics records created by or recognize updates to existing Dynamics records made by the user account designated for the data sync, because it would create a circular reference (endless loop of updates between Marketo and CRM database). The worst case scenario is that you connect your new Marketo instance to Dynamics and then upload leads and contacts into Dynamics with the same user account used for the data sync. You would end up with an entire Dynamics database that cannot be pulled back into Marketo and you would need to start over.
Here are some other important details to note on this Dynamics user account
- Make sure this designated Dynamics has an email address associated with it. Unlike SFDC user accounts, Dynamics accounts do not require an email. Marketo does require it though, so that’s why it’s needed.
- Make sure the password is set to NEVER EXPIRE. If you don’t do this, the password expires in 90 days and the data sync will fail. Marketo keeps a log of the failed transactions and will backfill them when the sync is restored but this is clearly very disruptive potentially to the business.
· Do you use single sign-on for Outlook, Dynamics, and other network-hosted apps?
Marketo will not be able to authenticate your Dynamics user account login credentials and you will be unable to initiate the Marketo-Dynamics sync.
Get your network admin, Marketo pro services and your consultants collaborating to figure out how to get past this single sign-in block. We lost 2-3 weeks waiting for them to figure it out.
· Prepare Webex, or other webinar hosting service programs, in advance in your new Marketo environment.
During your transition period you will probably have live webinars that you are running in your outgoing environment, but will need to wrap up in your new environment. To make this transition seamlessly, you can connect one Webex event (or other vendor event) to the same Marketo program in 2 different environments. Since you can only connect a Webex event to a Marketo program BEFORE there are any members in it, you should establish the connection right when you get your new environment for webinars that are in progress (occurring during your transition period). You will eventually need to import lists into this program in the new environment and specify who has been invited, registered, etc. Establishing the connection before you do any of these list imports eliminates this problem.
· Do NOT import lead lists into your new Marketo environment until the Marketo-Dynamics data sync is established.
Why? If you try to get a head start, by let’s say, importing your unsubscribe list in advance, Marketo will create duplicate records when the Marketo-Dynamics sync is initiated. This is the one occasion where Marketo does not recognize an existing email as a unique record. You want your new Marketo environment to have ZERO leads when you initiate the Marketo-Dynamics data sync.
· Work with Marketo pro services and your IT department to make sure your landing page and image URLs are the same when you switch from your old environment to your new environment.
At the time of this posting, Marketo is working on a more automated and elegant solution, but in the meantime, collaborate with these knowledge experts and you will not have to manually create redirects for every URL you need to manage.
· Do NOT create too many user roles in Dynamics and create an overly “closed” system
Instead of having a few user roles, with substantial rights and permissions, our team decided to take a very fragmented approach, creating very specific user roles (Marketo Sales Insight for example) with very limited rights. Users then need to have a “bundle” of roles in order to have all the rights and permissions they need. It’s a nightmare to manage and we’re still dealing with people being unable to see each other’s reports, etc. 3 months in.
· Beware of Date/Time vs. Date Only field types if you have date fields mapped to corresponding fields in Dynamics.
Dynamics does not have the concept of a Date field. They only have "Date + Time". If you migrate an existing Date Only field from your old Marketo instance it will be mapped to a Date + Time field in Dynamics. If you create a new Date + Time field in Dynamics and pull it back to Marketo, Dynamics gives you the option of how you want to display it in Dynamics = Date only or Date + Time. Your selection here will determine the field TYPE pulled back into Marketo. In other words, if you tell Dynamics to display it as a date, it, Marketo will create it as a Date Only field in Marketo. If you tell Dynamics to display it as Date/Time in Dynamics, it becomes a Date/Time field in Marketo.
This decision can have impacts if your date values ever get out of sync on this field between the 2 systems. In our case, a single text field being too short in Dynamics and a plugin failing to be turned on led to this outcome. Dynamics contacts are more problematic to fix because Marketo does not overwrite the Dynamics contact record if it finds a value that does not match what it expects to see (the old value on the Marketo record). There is only one way to get these records back in sync if you go with a Date Only field in Marketo:
1) Delete the date values in Dynamics via a spreadsheet upload into Dynamics (warning - it will take a LONG time)
2) Wait for Marketo to pull back the null value on all records
3) Reimport the correct date values back into Marketo
If you went with a Date/Time field type in both databases, you can simply do the following:
1) Upload the correct date values into Dynamics. Use 12 am as your time if you do not have one.
Note - all of this is for Dynamics contacts. Marketo can overwrite Dynamics leads data when records are out of sync so you can import directly into Marketo if you wan to fix leads in Dynamics on your own.
Also Note - the time zone setting of the Dynamics user account used for the upload into Dynamics does matter so you will need to test. In our case, a user account with a PST setting led to an exact time match when pulled back to Marketo, and a GMT setting led to an 8 hour difference.
Part 4: Post Go Live Activities
· Remain vigilant! Monitor and Test
Create views and reports in both Marketo and Dynamics to ensure lead pass-thru and other key functions are working properly. As an example, I have a leads view in Dynamics that I check daily to see leads that have been created or updated today. If it is empty it means there’s Marketo-Dynamics sync has been disabled.
· Do NOT trust data values of fields that originated in your old CRM system after you have made your CRM system read only.
We made our SFDC instance read only a couple weeks before we were able to go live in our new Marketo-Dynamics environment. During this period, Marketo was able to add existing SFDC leads/contacts as campaign members in the read only SFDC environment. However it wasn’t able to update fields on the lead or contact record, like custom fields we have such as “First Campaign Name” or “Last Campaign Response Date”. There was a strange disconnect where the correct new value was appearing on the lead record in Marketo, but if you ran a smart list, Marketo would display the outdated SFDC value.
Part 5 - Addendums
March 2014 - I have another painful lesson to pass along. We migrated from Dynamics 2011 to 2013 about 1 month ago. Immediately after the migration we started to see contacts in Dynamics fail to update when they responded to campaigns. About 90% of all contacts were affected and the sync would fail in both directions - update the record in Dynamics and Marketo would fail to pull the update back into the corresponding Marketo record and vice versa. After weeks of MS, Marketo and my IT team investigating logs and testing various theories we discovered the problem.
In Marketo, we have lead and contact dedupelication settings - see screenshot below. Even admins like myself can't see this - only Marketo engineering has access apparently. In any case, for Contacts it must be set to True. Like I said, as an end user you have no visibility to this, but if you migrate to Dynamics 2013 I strongly recommend submitting a support ticket and have someone in engineering verify your settings are correct. You want the Contacts to be set to TRUE. It's a non-factor in Dynamics 2011 but becomes a very big deal in 2013.
.png)