Is a migration roadmap available?

Hello,
Is there somewhere, or could we have somewhere a roadmap of the migration ?
I mean

  • the period of time where we expect gateways to be migrated
  • date where console.thethings.networks becomes v3 as a standard
  • date of end of v2 infrastructure
    It will help to synchronize and also to have people on time for the migration
1 Like

You are a bit impatient?

Only EU has V3 at the moment. Let’s wait until the other regions have their V3 clusters and we all have been able to check what is involved in migration our nodes.

Currently people in EU are trying to find if a node can be migrated online or requires a visit. Other regions don’t have that opportunity yet.
Gateways will probably require visits to reconfigure. For those nodes and gateways where on-site activities are required these are severely restricted in most countries around the world at the moment, that needs to be taken into account.
And as TTNs crystal ball is not better than that of most governments it would be a miracle if they can currently create a reliable timeline for anything exceeding weeks.

The provisional timeline communicated during the conference was:
April V2 read only
September switch off

However that already prompted the feedback that those timelines would be impossible to achieve in some parts of the world due to travel restrictions. And Johan promised TTN would not to put anyone’s live at risk.

5 Likes

If v2 is readonly in April (means we can’t add anything more in … I think we are on the rush because the impacts are large, even just for migrating devices from v2 to v3. As we have seen, this alos requires to upgrade some of the gateways to still relay traffic on v3 even if still on v2.

But my question is more about a general planning to be in sync altogether, like saying to people, the right period to migrate your gateways is July - August.
Ensuring your v2 gateway will continue to route v3 traffic ; February - March
Migrating your applications and devices March - July

This is to avoid everyone going in different directions.

I think we’ve all achieved that milestone :wink:

Are you hoping to find a solution to cat herding? I understand the general idea of getting people in sync but if you scan through the topics we have people at all levels and human nature means many people will leave everything to the last minute.

I think the best we can do is to keep saying “Migrate gateways last” so that those who do leave their device migration late will still have some coverage.

As for TTI, they can see how much is still flowing through V2 but even if it’s a significant chunk of devices, it’s just not in their interests to buy more duct tape to keep the old stack going - at what point do you call it time?

A agree that this migration is a challenge, also that TTN is a community network, by the way if anyone commit anything anytime in Linux kernel at the end the adoption will be lower, because it will kernel panic too often

I’m locally do my best to offer a high quality network that can compete against public operators because I think TTN model is really interesting in the future. It means we need to capture professionals/commercial applications and as a consequence having a correct SLA.

Honestly, I can manage a such upgrade as a project locally and limit the impact for users (even if they are not a lot, but this is not a reason to make it badly). But if we want to have an efficient migration globally and not having this period of time quoted by all our competitors for the next 10 years, we should not only considering this as a technical operation but as a project, with phases, synchronization, progress KPIs.

So, as a local Initiator trying to execute and animate the migration locally, more information I can access about a global planning and progress, more I am able to synchronize with others.

My two cents.

2 Likes

Also see: