Sounds good. I’ll hold off getting v2 Hub until this goes live.
I doubt if the planned migration tool is going to actually unpair and pair individual devices without requiring you to physically handle them.
I think instead, it’s intended to help move smartapps, routines, and other software bits.
Of course no one knows for sure, but Be careful in setting your expectations.
Although there is a way in Z wave to transfer control from one controller to another, smartthings has as yet not implemented the commands of that requires. That would be a big change.
And Zigbee doesn’t have that as part of their standard. A few companies like control 4 have implemented a means of doing it, but it requires some additional stuff at the time of network set up, which obviously smartthings didn’t do.
So I just think it’s unlikely that we’ll be able to avoid physically pushing the reset button or whatever on each individual sensor and switch. That’s considered a security feature in both Z wave and zigbee because it makes it much harder for a hacker to grab control of your network’s devices.
Thanks for the tidbits and good to know. I’ll watch for it when the “migration assistant” becomes available. Even if I have to do some manual transitioning, at least having my apps and some of my settings moved over would be great. Anything that can speed up the work. 
@mallardnathan Well, it depends on how long you have your system, but I don’t think it is a bad idea to break everything down and re-install to keep the system optimized. I guess, it really depends on how many apps you have, i’ve been cleaning mine up and removed a lot of apps that i didn’t need anymore now that those functions can be easily added through new supported SmartApps.
I’ve been cleaning up mine as well and moving more toward newer apps, but my biggest issue is some of the apps I’m using are R&D apps for a company I work for (I can’t talk too much about it yet, but visit weatherbughome.com and you’ll get an idea of it), so unless I direct migrate those, our teams would have to do more backend re-configuring work to my system that I’d like to avoid.
I agree and don’t understand why that step was not made a priority and relatively minor project by SmartThings. As such, I wouldn’t hold my breath for a migration tool. ST takes a much longer time than expected for some of the most desired functionality.
Ref this Topic and others…
Actually, SmartThings staff (including CEO, I think) have publicly stared “by the end of the year” (or wording with that implication). Not that I have any confidence in that.
“200 + devices in 3 hours…”
Yes, Screenshot or it didn’t happen…
That is the process I followed. I went through a general exclude from the V2 Hub and then paired them up fresh on the back of that. Worked well for me.
Can you guys explain a little more about that? I am contemplating the minimote-route (figuring out what that process is; I used it to pair something like a year ago and forgot what I can do with it) or something else rather than wait for 4-6 months for a migration tool that I don’t expect will be able to automatically facilitate zwave devices switching hubs without intervention, as I keep adding devices at family request (at 122 now). General exclude from v2? How? Don’t you have to exclude each device one by one from V1 first??? I (and others) might miss the blindingly obvious in your statements…
I played it safe.
I used a minimote still connected to v1 to exclude from v1 (slide the panel open, hold near the device and click the remove button), it will flash red, then for each device click the reset function, when the minimote exclude is done, it flashes blue. then on to the next.
From here you begin the include process as normal on V2
so in theory, have one minimote on v1 and one on v2, and really hustle getting things unpaired and paired again! 
issuing a general exclude
“General exclude”"just means any zwave controller can issue the exclude command, it doesn’t have to be one that was previously paired to end device. But you still need to do whatever the button push protocol is on each individual end device to get it to accept that exclude.
A minimote counts as a Zwave controller for this purpose. It has a button inside its slider compartment that issues that general exclude command.
So you push that button, walk up to the end device you want to exclude, do whatever procedure it needs to accept the exclude, and then go onto the next device. Way faster than using the phone app.
It is true that each zwave device must be excluded from its previous network before it can be included to a new one.
should you include as you go, or exclude everything first and then come back and include?
Some people like to exclude all the devices first, then stop and think about things, and then set up, maybe just a few devices at a time.
Other people like to exclude device a, include device a to the new network, exclude device b, include device b to the new network, etc.
There’s no one right way. If you know you’re going to move all the devices over, it might be a little easier to exclude, include, exclude, include, but there’s no harm if you want to do all the excludes first. It’s just a personal preference.
Should you use the Minimote to include?
The question of whether you should do the include with the minimote gets trickier, because if you do the include from the phone app you’ll get prompted to do a bunch of set up stuff, like assign it to a room, which you’re going to have to do at some point anyway.
Everybody’s going to handle this somewhat differently.
My method is a little different yet, because I can’t really physically work A Minimote. I have to have someone to help me.
But if I were more physically able, and I were moving over all my devices, I would probably exclude from the Minimote then immediately include from the phone app. Complete in app configuration, and then Move on.
Setting parameters on a battery powered device
There’s a particular issue that comes up if you need to do any parameter setting on a battery powered device. Battery powered devices will only accept parameter changes if they’re awake. The problem is they like to sleep. At the moment that you do an include they actually stay awake for the longest period of time.
So I like to do parameter configurations immediately after an include, because I have the highest chance of the device actually being awake and accepting them. Rather than going back and trying to do them later. But that’s just me.
Wasn’t SmartThings working on a device replacement option? I mentioned this a while ago
I thought this was going to be a “subset” of the full migration. I continue to be worried about having to replace a critical device that might be in a dozen or more smart apps, like a main motion sensor or a light switch in the kitchen (most common area in our house).
Aha, I did not know that. I thought the owning hub had to do so. Now that I think about it, that does make sense it wouldn’t have to but it had not computed until now.
This existed in the previous version of the app, but is only for Z wave devices. If you have a new zwave device of exactly the same model, you can use it to replace a broken device.
One of the reasons this works is because, as previously mentioned, Z wave devices do not have to have A unique manufacturer-assigned ID, so the network can just give it the same ID as the previous one, and you don’t have to change any of your smartapps.
Won’t work for your zigbee sensors, though.
This type of leap in logic drives me crazy. 
The internal database reference key for the Device Instance Object is entirely separate from the Physical Network ID.
It is a little LOT like the difference between an IP address and a MAC address:
- one can be changed entirely without affecting the other.
For device replace, SmartThings could easily lock the Device Object for exclusive access while it updates the network connection and all other properties (ZigBee ID, Z-Wave ID, DNI, Device Type, Label, etc.) but can absolutely retains the Device Object ID.
This could even work for Devices that move across Locations, if SmartApps ever support multiple Locations
No, it’s not a leap in logic, it’s part of the underlying protocol (in this case zwave) which is not controlled or designed by SmartThings.
The SmartThings hub is a certified zwave controller. Consequently it adheres to the Z wave standard. In that standard, the device’s network ID is assigned by the primary controller. The device is told its ID by the controller at the time of inclusion.
So in a zwave replace, the controller takes the old network ID and tells the new device that that is its network ID.
It works precisely because the zwave protocol is built on the idea that the primary controller will tell the individual device what its network ID is.
None of the other stuff you mentioned applies in this particular case. This is a Zwave activity involving the inclusion of a zwave device.
I’m saying that there is no reason SmartThings couldn’t have written the “Replace” Feature to work with any kind of Device.
The fact that it was done and implemented a particular way for only Z-Wave is not my concern. There are no restrictions on SmartThings’s back-end database design that should prevent generalized Device Replacement (i.e., without requiring SmartApp reconfigurations).
Not true.
There are restrictions based on being certified by z-wave and certified by zigbee.
As a certified Z wave controller, the Smart things hub cannot interfere with the normal activity of other certified Z Wave devices on its network. Meaning they still have to be able to operate with direct association, using the network IDs that are assigned to them at the time of inclusion in this network.
You can’t have a software lookup for that and meet the zwave standard. If I want to associate a Leviton master light switch to a Leviton aux switch, both certified zwave devices that I have included in my network, they have to be able to talk directly to each other without going to the hub at all, let alone any kind of database lookup you had in mind.
They both need to know their network IDs, their neighbors need to know their network id’s, and they have to know it without going to the hub.
If smartthings were going to design all their own devices, and design their protocol, then they could do exactly what you described. But they wanted the advantages of being an open platform, and they signed up to be certified controllers with several different independent protocols. That comes at a cost. And the cost is that you have to use the addressing schemes that those protocols come with.