Serial entrepreneur has 10ths of business. Many are running their own mautic instances in their domains.
Now a couple of businesses are to be merged and the user-base managed from a single source-of-truth.
How can I merge 2 mautics into 1 so ALL the funnels ar kept, and ALL the users are kept in their current states, and no information is lost, and later on users are merged by email so if in instance A user Alice was in funnel X and in instance B Alice was in funnel Y now in the new instance Alice is both in funnels X and Y at the same time?
Hi, this is really tricky. In each instance contacts have their own IDs. So do events, campaigns, and everything. If you have 2 instances, you would need to renumber everything what doesn’t match. I don’t see this happening.
Better to a migration plan, where you redo some campaigns and place people in the right spots.
Plz don’t ask how: if you don’t know how the campaign events work, then a Mautic professional has to do this for you. It will be a long complicated road paved with mistakes and accidetly launched emails.
Joey
If the only handicap is id collision, I’d go better for the renumbering, not for manually rebuilding everything in the other.
Do the IDs map field-by-field in the mysql (for example: Contact 333 has submitted form 444) in such a way that I can do by forcing CASCADE UPDATE in the relational database?
Or there is “hidden data” in “text-like strings encoded with more thinngs inside fields” like one field having for example a JSON approach to store things and then it has to be read-decoded-interpreted-modified-recoded-written?
I am happy to renumber “everything” in one of the mautic instances to start for example above 1 million. So user 333 gets to 1000333 and the form 444 gets the id 1000444.
There is so much that can go wrong with this. I mean merging mautics in a sense that all data from database A will now go to database B while keeping original content in database B.
IDs are just the first task. There is also serialized data that would need to be updated, structure (custom fields) is probably not exactly the same between instances etc. There are additional things you will discover that we do not even see it, once you start.
Any solution here in terms of search and replace will likely result in broken mautic instance or incomplete migration.
My bet here would be solution along the lines:
backup everything all the databases, all the source before you attempt anything
identify what data do you really need from database A (locate the tables) - you probably do not need audit_log all the forms etc.
study the structure of those tables
write the script that goes over each lead in the database A and updates or create record in database B
test before running against real databases
High overview above is massively simplified, the exact plan should be made after investigation of your needs and requirements.
And like @joeyk said, if you do not know mautic inside out, hire someone to do this for you, because even for someone that uses mautic on a daily basis this can present quite a challenge.