There’s no reason that the back-end data couldn’t be 100% cloned from 1 Hub recordset to the new one. – All that is needed is to create a temporary set of Device Records, if foreign key constraints can be temporarily disabled during the account’s migration.
I’m 100% serious:
Given full access to the SmartThings device Cloud database for a single account…
Very rough pseudo code / sketch:
Lock the account and database for migration mode, limiting what functions may be performed; disable foreign key constraints. Add a friendly alternate candidate primary key – heck, use the Label Attribute (e.g., make the user ensure all the Things have a unique name by using the existing Properties/Rename function in the UI). Add a temporary column to mark “devices set for replacement”. Remove the device but don’t delete any of its Cloud data. Add the device to the new hub in a temporary table row. Prompt the user to confirm or assist in matching it to the non-deleted Device record by using the unique friendly-name key we ensured above. Move the data from the temporary table to the correctly keyed record in the existing device table, thus resulting in it having the same main primary key (Device GUID).
All related records (Events, Shortcuts, Group, SmartApps, etc.) require no further updates as all their references to the Device are via the unchanged GUID.