Please do a search here for CNAME and company changes. It's been discussed in detail. Also docs.marketo.com has two pages on this.
Account String is your backend name for your instance. AFAIK, it cannot be changed and it is kind of irrelevant except to certain things and Support.
2 of 2 people found this helpful
1. Do we need to change the account string, i.e. is it ever visible in tracking links or landing pages?
It's not visible anywhere to the casual end user. However, a nosy user can see your account string merely by pinging your LP domain (the DNS lookup output will include the string).
dig pages.example.net ;; QUESTION SECTION: ;pages.example.net. IN A ;; ANSWER SECTION: pages.example.net. 3600 IN CNAME youroldcompanyyikes.mktoweb.com. youroldcompanyyikes.mktoweb.com. 300 IN A 18.104.22.168
If it's the kind of merger/takeover where if you really need to hide any trace of the old company, I believe under urgent circumstances Support can give you a new account string.
2. If we do change the account string, will existing landing pages and emails tracking links still work?
Not if those hostnames are aliases for an A record (the account string hostname) that no longer exists! This is the real problem with changing the account string, if we allow that it's theoretically possible on Marketo's side: if only one account string A record exists at a time and the other one is completely removed from Marketo's DNS, it would take some tricky coordination to make sure that old records and new records both work. Of course a sophisticated DNS shop would be able to hold your hand and do this without errors by aliasing the old account string to the new one, but I'm... not sure... that's what you're going to get from Marketo.
Thanks, Sanford Whiteman. We asked Marketo - support referred us to our Account Manager who said that they can change the account string for a fee. We have a sequence of operations from them, but because of the coordination that would be required, as you say in your post, I'm recommending that we actually do use their professional services to handle this, as we don't have enough pull with the various players to get the timing right. I'm concerned about the DNS records - based on my experience with another Marketo customer, it can take a number of hours for the changes to propogate.
I have suggested that we wouldn't need to change the account string, but as this is a significant merger, they would prefer all references to reflect the new company identity. We will see whether cooler heads prevail!
You're right to be concerned about extended DNS caching (my DNS mentor years ago discouraged me from saying "propagation"!).
Even if you set the TTL to very low (1-5m), there will still be sporadic outliers using the old value for up to ~48 hours.
But of course if the old value and new value both work, that's fine. If Marketo can guarantee that your IP address won't change (at least during a weeklong period), then you don't even need oldname.mktoweb.com to still be active in Marketo's DNS: you can use an A record in your own domain for that. Or if they can keep both oldname.mktoweb.com and newname.mktoweb.com active, or tell you the new IP address ahead of time, you're also good to go.
If there's a problem having both new and old active simultaneously (as in: the IP address will change) Professional Services alone can't solve that problem. In that case I would do the following to eliminate downtime (or reduce it to < 30s):
- set up a load-balancing proxy that balances old and new servers (called "origin servers" in the proxy world)
- set proxy to check liveness of both back-end servers every 30s and remove a non-responsive server from the farm
- point LP hostname to the proxy's hostname temporarily
- do the whole account string change, wait a week
- now point LP hostname to newname.mktoweb.com
- wait another week and retire proxy
In this scenario, you don't have to worry about lingering outdated DNS because all the traffic flows into the proxy first. From there you can manually or automatically switch the back-end server based on IP address. We do this when failing over to a disaster recovery site, et al.