Marketo Migrations are time-consuming and don’t drive any immediate revenue. Unfortunately, they are sometimes needed, like when you change CRM systems or merge companies. Automated migrations are faster, cheaper, more accurate and actually bring over more details than manual migrations. Continue reading to learn how.
Marketo migrations normally involve a lot of manual work: lists are exported and imported, folder structures and assets are rebuilt and there is lots of copy/paste. It always takes more time than you had expected and if you want to outsource, the agency proposals tend to be pricey. And most importantly: there will be errors and information will be lost as part of the migration. Before we go into details about automation, here are the different types of migrations:
This document covers how to automate Rebuilds, Instance Copies and Instance Merges. To keep this article somewhat concise, we can’t cover migration to/from other systems, even though that can also be automated. Option 2 - “instance copy” - is a bit different from 1 and 3, so let’s look at that first.
Instance Copies are done by the Marketo Support team and they copy all Assets over to the new instance, but not person records. Instance Copies are not possible for all situations, for example, it’s not recommended if you switch CRM systems. Also, it overwrites everything in the destination instance, so it cannot be used for an instance merge. Finally, if you want to clean up this is not a good option because the instance copy also brings over things that you maybe don’t want, like test assets and all custom fields. But if it works for your situation, an instance copy will save you a lot of work. The parts of this article that apply to asset migration do not apply to instance copy migrations, but everything else still applies.
The goal of this article: with automation, you can take the pain out of migrations. We’ll cover these migration topics:
If your new instance will be natively connected to Salesforce.com or Microsoft Dynamics CRM, you will migrate a lot of the Person records via the CRM system. You load the records into the new CRM system, then sync the records to the new Marketo instance. However, it is very likely that you had some Marketo-only fields that would not be in the CRM system. Also, maybe some Marketo records were never synced to CRM. The migration of those records and those fields can be automated after the initial CRM sync is complete.
If you don’t have Marketo natively synced to a CRM system, you can migrate all person records over, including all desired fields. In both cases, you will need to have a field mapping for when the field API names in the new instance are different.
You could do this migration by exporting a list from the old instance and then importing into the new instance. However, exporting the List may take a long time, and the import file cannot be any bigger than 100Mb, so you may have to split your file before importing. Automated migration will make this easy, and it also includes automatic field creation and cookie migration.
If you have any Custom Person Fields that you want to migrate to the new instance, those can be created automatically. This is not needed for fields that come from a natively connected CRM system, it’s just for the Marketo-only fields. Migrating this automatically will ensure the API names are identical, which will help with Program Import.
Cookie migration is useful if your new instance will have the same Landing Page Domain as your old instance (after the migration is complete). Visitors will then keep their cookies so their web visits will continue to be tracked. Migrating cookies can only be done via the Marketo API, so the migration script can include cookies as part of the Person migration.
Nowadays, most Marketo users try to create as many assets as possible within Programs, but some assets - like templates, snippets and images - can only live in Design Studio. Other assets such as forms and lists are sometimes created in Design Studio because they are reused. For the latter, if you want to have them in a Program going forward, you could clone them into a Program and import the Program into the new instance (see the section on “Program Import” below). The cloning can be automated. If you want to keep them in Design Studio, automation can also help, let’s look at that for each asset type.
Snippets, Images & Files and Email and Landing Page Templates can be extracted via the API and then migrated to the new instance. Any links to images in Snippets, Email and Landing Page templates will need to be updated to include a new Landing Page Domain (if it’s not the same) and the new instance name (which is in the instance URL). Changing the links can be automated.
The folder structure can be migrated from the old to the new system. You can skip any test folders or archived folders that you want to omit, but the rest can be automated: no need to copy and paste.
Forms, Emails and Landing Pages could also be migrated automatically, but they’re a little trickier: first of all, they may use fields that no longer exist in the new instance, or the fields may have a different name. Also, these assets are a lot more complex. For example, Forms have visibility rules, dynamic follow-up pages and progressive profiling. Emails may have variables and tokens for fields that don’t exist anymore. Landing Pages may have custom HTML. In many cases, it’s faster to either clone them into a Program and import the Program into the new instance, or to manually recreate these assets.
Not all Assets in Marketing Activities can be created via the API, so using Program Import to move Programs into the new instance is still the preferred option. Marketo Support can link the two Marketo instances together, after which entire Programs can be imported (Program Import documentation).
Unfortunately Program Import can’t be automated, so someone will have to import Programs into the new instance one by one: only 1 Program can be imported at a time. There are also some things to be aware of:
If the old instance is still in use, clone each Program that needs to be migrated and then remove any field references, snippets and dynamic content. You can then import the clone into the new instance.
Since assets with Snippets or Dynamic Content cannot be imported into the new instance, automated scripts can back up Dynamic Content and Snippets and remove them from the assets so you can import them. After a successful import into the new instance, the script can restore them again. The more Dynamic Content and Snippets you have, the more it pays off to invest in automation.
It is also possible to recreate the folder structure in the new Marketo instance. While technically it’s possible to migrate Program Tokens on Folders, it’s often better to do that manually because the API can not distinguish between local, inherited and overridden tokens.
If you clone the Programs before you import them into the new instance, their name is different, and thereby the URL for the Landing Pages will be different too. If you need the landing pages URLs to be the same in the new instance, you need to fix the landing page URL after importing them into the new instance. This is also something that can be done automatically.
Since there is no API to create Segmentations, those will need to be recreated manually. There is also no API for Smart Lists, but you could consider cloning them into a Program in the old instance, then migrating them over to the new instance.
It’s possible to automatically migrate the folder structure, although it’s rare to have a very complex folder structure in the Database section.
It’s also possible to automatically create Static Lists and in one of the following paragraphs we’ll show how to also migrate list membership.
Migrating Program Membership is important so you know who responded to which Programs. Automated migration uses two mapping tables between the old and the new instance:
With that mapping, it’s very easy to automatically export members and their statuses from the old instance, and restore those in the new instance. This can also include Program Member Custom Fields, assuming you’re creating similar fields in the new instance.
The one thing that cannot be restored is the Program Membership Date: it can be extracted, but it cannot be restored in the new instance. That could potentially impact some reports. You could theoretically save it in a Program Member Custom Field so you have it, but it won’t be used in Marketo’s built-in reports.
While List Membership is generally less critical than Program Membership, it’s easy to automatically migrate. Again, you need to have a mapping for Lead IDs and List IDs, and after that it’s a pretty automated process.
While it’s not possible to create “native” activities in the new Marketo instance, it is possible to create Custom Activities. Migrating activities is not always useful, but it’s relatively easy and it’s good for peace of mind. This is how it works:
The creation of the Custom Activities and the migration of native activities to the new Custom Activities can all be automated. Just keep in mind that it’s a completely different activity, and the migrated activities link to assets that may have different IDs and/or names, or the assets may not exist anymore at all. As an example, any migrated Smart List that uses the filter “Was Sent Email” will need to be edited to replace it with a “Was Sent Email Migrated” filter, and then you need to enter the name of the migrated Email (usually the same, but not always).
If you have a lot of users in your old instance, it may be useful to automatically migrate them to the new instance. It makes it easy to send all invites at approximately the same time, without having any typos. Even if you use SSO, you still need to create a user in Marketo to assign the proper roles, but the timing may be less critical since it doesn’t send an invite. Roles can’t be migrated automatically, but the script can assign the correct Roles to users.
Once people stop using the old instance, you can also automatically remove their roles and assign a role with no permissions. You could also set an expiration date, or delete the users altogether.
When you are migrating, you don’t want any Smart Campaigns to be active in the new instance. But once your new instance is live, you suddenly want to activate all of them. This can be done automatically. At the same time, you probably want to deactivate the Smart Campaigns in the old instance. Recurring batch campaigns will need to be disabled and enabled manually.
In short: automation can make your Marketo migration a lot faster, a lot less painful, and a lot cheaper. Anyone who is familiar with the Marketo API will be able to create such migration scripts. However, from personal experience we know it’s quite hard to get it right the first time. Momentera has a library of Marketo migration tools that is battle-tested and can be deployed at once. We’re happy to talk more about your specific migration requirements to see how we can assist you.
If you want to make another big step forward, consider using Stack Moxie for automated testing. This will allow you to confirm that all migrated programs are working correctly, now and in the future. This is not a Momentera product, but we recommend it.