Possible starting points are:

• do we retain the wiki's names?
• how do we rewrite concept URIs?
• do we retain all history or just "the current version of entities"?
• How do we associate platform user accounts with wikis?
• How and when do we lock wikis on wbstack.com before migration?
• How do users confirm they are willing to be migrated?

It could be that the outcome of this should lead to some updated thoughts on T295078

My thoughts:

In T297867#7582651, @Tarrow wrote:

• do we retain the wiki's names?

Names or domains?
Names are easy to retain, domains would be more work but not impossible.
The easiest way to retain domains (if folks want) would be for them to be managed as custom domains in the wikibase.cloud landscape perahps?
The best solution for us would be to not need to keep these old domains, but instead do some redirects.

• how do we rewrite concept URIs?

As in how do we load data into the query service?
The "easiest" way would be to add all entities that are imported to the "changes" table that the updater reads, then the updater would just correctly add all of the data to the query service backend.

• do we retain all history or just "the current version of entities"?

Personally, I would say all history.

• How do we associate platform user accounts with wikis?

I don't understand what this one means?
I imagine user A on platform will ask for wiki B from wbstack to be migrated.
We will verify that and assign the moved wiki to that user.

• How and when do we lock wikis on wbstack.com before migration?

Before makes sense to me (as long as these migrations don't take weeks, which they shouldnt

• How do users confirm they are willing to be migrated?

Email?

In T297867#7595527, @Addshore wrote:

Names or domains?
Names are easy to retain, domains would be more work but not impossible.
The easiest way to retain domains (if folks want) would be for them to be managed as custom domains in the wikibase.cloud landscape perahps?
The best solution for us would be to not need to keep these old domains, but instead do some redirects.

redirects can be fine. The name thing is what I was wondering about. There is a risk of collisions se we might want to reserve wbstack names now (by name I mean the non opencura bit of non-custom domains).

• how do we rewrite concept URIs?

As in how do we load data into the query service?
The "easiest" way would be to add all entities that are imported to the "changes" table that the updater reads, then the updater would just correctly add all of the data to the query service backend.

I think you're implying we totally rewrite concept URIs to match whatever the new wiki domain is? e.g. we don't allow people to keep any opencura conceptURIs they have? They just "become" wikibase.cloud ones.

• do we retain all history or just "the current version of entities"?

Personally, I would say all history.

Because this is technically easier or because you think users actually have a strong need for retaining their history? I see that if we migrate all history we probably need to update wbstack wikis to run the same version of Wikibase as wikibase.cloud is running at migration time.

• How do we associate platform user accounts with wikis?

I don't understand what this one means?
I imagine user A on platform will ask for wiki B from wbstack to be migrated.
We will verify that and assign the moved wiki to that user.

Cool, so the assumption is that users will be required to make a new account on the new platform first (after we give them an invite) and there they will ask to move some wbstack wiki (or wikis)? Of course the opposite could be that people with an account on wbstack ask us to migrate and we both mint them an account and associate their wikis with it after we do the migration.

• How and when do we lock wikis on wbstack.com before migration?

Before makes sense to me (as long as these migrations don't take weeks, which they shouldn't

• How do users confirm they are willing to be migrated?

Email?

Maybe need to have some workflow to prove they actually own the wiki before we migrate it

Could be something looking a little like this: