Expand my Community achievements bar.

Announcing the launch of new sub-community for Campaign Web UI to cater specifically to the needs of Campaign Web UI users!
SOLVED

Migrate Adobe Campaign V7 On-Prem Instance to V8 Adobe Cloud

Avatar

Community Advisor

Hello,

 

I have a question related to Adobe Campaign V8 migration.

We have a client that is currently on on-prem V7 and looking forward to migrating to Adobe Cloud V8. They have a hybrid architect.

 

According to our analysis we are looking for the following path:
1. Move the V7 marketing server from on-prem server to Adobe Managed cloud service.
2. Migrate V7 to V8 on Adobe Managed cloud server. 

 

We do not get the clear answer from Adobe how they migrate the current data of on-prem marketing server to manage cloud.

 

As per my assumption, we might need to do the following step:

Steps:1. First we need to configure Adobe Campaign env. on Adobe cloud. For e.g. we need to export all the custom schema, forms, JS, webapp, reports, workflows, campaign, delivery etc. via package from on-prem to Adobe cloud.

 

Step 2. We need to import all the technical and functional data via files. For e.g. data of recipient, broad logs, tracking logs, and other functional data.

 

Can you please let me know if you have any experience in this type of exercise and if yes what is the steps to migrate and how much time it will take?

 

Feel free to share this message to someone who have this experience.

 

Kr,

Parvesh

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Employee

Hi @Parvesh_Parmar 

To make it short, the reason you don't get a clear answer on moving the data is because Adobe does not take the responsibility to move the data from on-prem instance to hosted instance and you have a significant migration project in hand to do so. In a nutshell, the migration project will involve

  1. Revisit your data ingestion processes: if you have follow ACC architecture principles, you would load data via flat files and you would have to do a initial load of your main customer data
  2. When it comes to communication history (delivery, delivery logs, tracking, exclusion, bounces), you will design a solution where you would keep in sync these entities in your 2 on-prem and hosted instances (extension of the schema by adding a 2nd ID and building files to export/ import the history between the 2 instances and keep your typology rules effective (depending on your approach, you would have to revisit these rules but there are way to do it that do not introduce any impact)
  3. Doing the above will ensure you that you can migrate your campaigns over a long period of time
  4. The tricky part is the sender domain, in ideal circumstances, you would define new sender domains for the hosted instance (that you would ramp-up of course). Doing so will avoid overcomplexity in the tracking server configuration

You would have to review all your endpoints for the ACC landing pages and APIs (if you use them)

 

We had customers having done it successfully in the past although if the on-prem deployment doesn't follow some architecture principles, the road to migration can be more or less complex and you need to plan it carefully of course....

 

You should definitively engage Adobe Consulting Services who would help you in shaping the migration activities avoiding pitfalls along the way. 

 

Hope this helps,

Thanks

Denis

 

 

View solution in original post

8 Replies

Avatar

Correct answer by
Employee

Hi @Parvesh_Parmar 

To make it short, the reason you don't get a clear answer on moving the data is because Adobe does not take the responsibility to move the data from on-prem instance to hosted instance and you have a significant migration project in hand to do so. In a nutshell, the migration project will involve

  1. Revisit your data ingestion processes: if you have follow ACC architecture principles, you would load data via flat files and you would have to do a initial load of your main customer data
  2. When it comes to communication history (delivery, delivery logs, tracking, exclusion, bounces), you will design a solution where you would keep in sync these entities in your 2 on-prem and hosted instances (extension of the schema by adding a 2nd ID and building files to export/ import the history between the 2 instances and keep your typology rules effective (depending on your approach, you would have to revisit these rules but there are way to do it that do not introduce any impact)
  3. Doing the above will ensure you that you can migrate your campaigns over a long period of time
  4. The tricky part is the sender domain, in ideal circumstances, you would define new sender domains for the hosted instance (that you would ramp-up of course). Doing so will avoid overcomplexity in the tracking server configuration

You would have to review all your endpoints for the ACC landing pages and APIs (if you use them)

 

We had customers having done it successfully in the past although if the on-prem deployment doesn't follow some architecture principles, the road to migration can be more or less complex and you need to plan it carefully of course....

 

You should definitively engage Adobe Consulting Services who would help you in shaping the migration activities avoiding pitfalls along the way. 

 

Hope this helps,

Thanks

Denis

 

 

Avatar

Community Advisor

Hello @costa_n11

 

Thanks for your reply.

 

For the point 4, we do not have any issue. Our IP and domains are hosted on Adobe mid server and we are not going to change it.  

We just need to migrate Marketing server or you can say Application server.

 

I would like to discuss point 1 and 2 little more , to understand it better. 

 

1. For the point 1, As I understood, we need to load the customer data via flat files. 

 My question, Do we need to ingest it as a fresh data? I mean adobe campaign will create new recipient primary key for each customer Or we can  use the existing recipient id.  

For e.g. Communication data is currently based on current recipient id. If we ingest the customer data as fresh records and create a new recipient id, then it would not link with the current communication data. 

Can you little bit explain how it was done for the client which migrated the data? 

 

2. For the point 2, I do not understand the solution you mentioned. Are you referring to import current on-prem communication data in same table, where old id will be store in different filed and campaign will create a new PK?  Can you please little explain it in more details with example to understand it better with? 

 

Thanks in advance!

Kr,

Parvesh

Avatar

Employee

Hi @Parvesh_Parmar 

A few points:

  • For the sender domains, I know you're in Hybrid, however Adobe mid-sourcing instances can't be shared between multiple marketing instances, hence my point that you would be better off having new sender domains with associated ramp-up. This will avoid headache down the line.
  • Data ingestion: these will be fresh data ingestion and the recipient ID will be new indeed....

Topic 2: yes indeed, I suppose you will not migrate as a big bang but you would migrate your campaign by phase meaning that for a couple of weeks you will send emails from both on-prem / hosted instances

 

  • However, during the communication history synchronisation (export / import to /from on-prem and hosted), you would have temporary 2 IDs: the hosted ID and the on-prem ID and you can use whatever is required for your reconciliation. 
  • Your own data will follow the same principles of reconciliation (using email address, your own IDs, etc...) and during the communication synchronisation you will also export the on-prem own id / recipient id association and stored it on the hosted instance and when importing the history, you'll reconcile using the on-prem id and vice and versa....SO during the parallel run, you will maintain the 2 IDs 

That's why such topic can't be discussed via a channel like the community as it can be very long conversation and that's why you have to wor with Adobe Consulting Services to nail down your migration project to the nitty-gritty as it really depends on your whole solution.

 

Saying that, for a data management point of view, these points above are quite easy to realise, you just need to ensure you keep the links between on-prem and hosted worlds.

 

If you plan big bang approach, aka switch off on-prem / switch on hosted in a single go, the above will still apply but much simpler. I don't expect a big bang approach but one never knows.

 

Hope this makes sense,

Thanks

Denis

Avatar

Community Advisor

Hello @costa_n11

 

Thanks for sharing this information. It makes sense.

 

You made a good point about the transition period. It would be challenging to do a big bang approach.

 

Setting up two marketing servers, one on-prem and the other on Adobe hosted cloud, is possible. However, I see some challenges in designing a solution to sync the environments, and it would only be a temporary and potentially expensive solution.

 

Earlier this year, I did a lift-and-shift migration. We exported the database from the local data center server database and imported it into the Azure data center server database. Because we exported the whole database, we could simply install the new app server and link it with the same database (which we imported onto the Azure DB server).

 

However, the Adobe techops team will not allow this approach on Adobe cloud.

 

Thank you for your insights. They will be very helpful in designing the migration plan and continuing the discussion with the Adobe team.

 

Kr,

Parvesh

Avatar

Community Advisor

@Parvesh_Parmar,
Just to add to already extensinve information provided by @costa_n11 

-  You could also add old primary key to v8 instance recipient schema. And simply import tracking data from old instance (you can create one export that has tracking, delivery, exclusion logs in one table), you do not even need to use schema for that just add all into a list. And when importing, you will reconcile recipient based on the old id coming from import and one you already have on recipient table.


- Also you can use  2 different mail servers for the same domain name.

 

Marcel Szimonisz

Avatar

Community Advisor

Hello @Marcel_Szimonisz

 

Yes, our first approach will be to see if we can import all of the existing data (e.g., recipient, broad logs, tracking logs, etc.) in the same form with the same key.

 

However, I see,  we need to take care of the sequence of the primary key when importing the primary key from the old data.

But i think this approach going to helpful if we go to big bang approach, I mean we switch off on-prem and turn on the hosted server.

 

Thanks your suggestion.

 

 

Best regards,
Parvesh

 

Avatar

Employee

Hi @Parvesh_Parmar and @Marcel_Szimonisz 

I will be extremely careful on the following "you can use  2 different mail servers for the same domain name".

On ACC V7, although technically possible, in fully hosted instances, this is not a standard configuration and you will request a configuration that goes against Adobe's internal processes, will most likley break certain tools  (Adobe Campaign Control Panel for instance) and will require an exception in all cases. The lengthy process this will take to get it done and the issues it will bring will not overcome creating new sender domain and executing a ramp-up...From experience, such configuration is very tricky to get done...

As for the data, you could of course load the logs as is in the hosted schemas saying that I suggest you keep the 2 set of IDs distinct, much more safer if anything goes wrong, replay, etc.... 

 

Of course in a big bang approach you might not bother but if you choose parallel run (aka the 2 instances sending emails along for couple of weeks / months), then it'd be safer to keep the IDs separate....

 

Just thoughts from experience on these topics,

Thanks

Denis

 

Avatar

Community Advisor

Hello @costa_n11

 

Thank you for sharing your experience and knowledge.

I now have a better understanding of the challenges that we will likely face in this project.

 

Thank you again for your support.

 

Kr,

Parvesh