Smart Transfer - Custom Object Transfer

Joshua Oakes flagged this one ahead of the call with Chris Carolan, and the board shows it in Public Beta with a scheduled release, expected November 9. His first reaction was a pendulum swing: when he clicked on it that morning he went from “oh, my goodness, what is this going to be?” to the screenshot at the top of the panel, and then to the panel's why-it-matters, which he said reads like a restatement of the description. He quibbled with “often need to import critical custom object data”: “if they're transferring from these systems, they absolutely need to do it.” If the system can do it without manual modeling, remapping and import, he said, that is even better. He also noticed the word is transfer, not sync, and wondered whether the Salesforce sync on the other side could operate against these records.

His advice for anyone migrating: “Now, this is a beta. So don't just turn it on, sync your objects, cancel your Salesforce contract, and walk away. You'll want to do that eventually. But join this beta and do some test migrations and see that everything comes over.” He said, “I rejoice on behalf of anybody who has to do this,” and that he was “especially excited for people in greenfield situations. Brand new portals where you're migrating in.” He is still curious what the mapping process looks like. He expects checks against any existing data model, infrastructure, syncs, ETLs or circuitous routes through other syncs: “there's still going to be a little bit of homework, but it'll drastically reduce it.”

The mapping trap, in his words: “the classic in mapping is, oh, we're mapping this property to that property and not thinking about the custodianship of either of the property, how it gets set, and then what its downstream dependencies are.” He said the value at the time of movement matters too, and how it affects other processes. Then roll-up properties: “I was doing a bunch of work with roll-up properties over the weekend. And they are fantastic. The problem is they are snapshots of associations…” A roll-up or sync property captures the value at the moment, he said, and “business processes exist in time, not just in a snapshot.” His example was pointing a sync property on a lead or deal at the contact's most recent traffic source to report on the source of the deal. The contact came in through organic social, then clicked an email and came in again as marketing email, so the lead source changes every time the person interacts with anything, and “your reports are varying degrees of inaccurate, depending on when you look at them, which is not what you want.” If the property needs to be persistent, he said, you go through the pain of copying the value via workflow into a property that holds it.

Chris Carolan's caution: “the likelihood that the way that processes were done inside of these systems should be the same exact processes that are done inside of HubSpot, usually low.” That is why manual modeling and remapping are super important to understand, he said: this is HubSpot's data model and this is how processes will work here. He warned against picking and choosing objects without knowing what your data model and the map look like. Breeze or any AI makes it easier to get ahead of the trap, he said, but “your goal as the human with your judgment is to figure out exactly where that should be.” He closed on the people side: “if you're expecting anybody to move into a new system, it'll take them weeks to get past the new interface. No matter how easy it looks.” In his opinion, the reaction of wanting to make it like the old system is the one to prevent, because the team did not like the old system either.