If implementing a redesign of this blog wasn't enough, and if redoing its static generation code wasn't enough, in the past few days I've migrated from my original Nextcloud server to a brand new one.

Long-term readers of this blog will know I've been running Nextcloud for years. I use it for many aspects of the FOSS Academic Lifestyle Dream -- syncing files across computers, collaborating with people, scheduling appointments, running calendars, and video conferencing via Nextcloud Talk. While so many of my colleagues are on Microsoft or Google infrastructure, I am not. And I likes it that way.

For reasons I will explain below, I decided to migrate my server from my longstanding original one to a new installation. I'll talk about the how and conclude by talking about the why.

The How

My original Nextcloud has been running as a Snap on an Ubuntu server.

I normally don't like Snaps, but I have found the Nextcloud Snap to be very reliable. It updates regularly so I don't have to worry about it, and I've not yet run into issues with updates. So I was quite comfortable simply setting up a new Ubuntu server and installing the Nextcloud Snap.

The next question was: how to migrate my account (along with those of my family, who use Nextcloud for syncing and backing up photos)?

Someone has built a Snap-to-Snap migration tool. I decided against Snap-to-Snap migration because I wanted a slightly different URL for my new server.

Instead, I just started rebuilding accounts from the ground up. And... much of it worked quite well! Some of it was a fail, though. Let's look at each in turn.

Triumphs and Joys

Most of the migration proved to be quite easy. One major task was to deal with shared calendars -- my family uses these heavily. I thought that would be tough, but no -- I just went to the original Nextcloud server (henceforth ONS), went into the settings of each calendar, and exported their .ICS files, then imported them into new calendars. Really simple. After that, it was just a matter of updating various Thunderbird installations and the calendars switched over without a hitch.

As for syncing files via the Nextcloud desktop client, that was even easier. I just closed the connection to the ONS on each of my client computers (a laptop and desktop), logged into the new Nextcloud server (NNS) on one client, and started the sync. The files uploaded from my first client to the NNS. Then I went to the second client, logged out of the old account, logged into the new account, and the sync took seconds (because of course the files on the other client were identical to the ones on the new server).

The final clients to deal with were phones. I use Nextcloud's Instant Upload feature to automatically back up photos taken on phones -- it's on all of my family's devices. Once again, it was just a matter of removing the old connection and starting the new one and making sure Instant Upload was running on each phone.

Bugs and Issues

I had one major failure and one mild disappointment, however. I could not migrate old Nextcloud Forms and Collabora (the browser-based document editor) is still performing poorly.

It turns out that you cannot easily migrate Forms -- if at all. You can make someone else a new owner of any given form, but that's limited to the individual server -- it doesn't federate.

Doing a bit of research, I learned about the Nextcloud Migrate User app, which claims to be able to migrate forms. However, it ultimately did not work for me. Here's what I did:

• I created new Forms user on the ONS
• Installed User Migration App on the ONS (and the NNS, since it is used for importing)
• Transferred ownership of forms (one by one) to the new Forms user. This is a very tedious process. It involves a lot of clicking and confirmation. It's under the Share menu in the Settings Tab, in case you need to use it.
• I did the export of the new Forms user from Original Server to New Server (to another, temporary Forms account). This took a very long time.

My intention was to complete this by transferring ownership of those forms to my preferred account. However, the import was a failure. I tried with two different accounts and the import did not work. I will have to report a bug with the Migrate User folks. Maybe the issue is Snaps?

It's not the end of the world because I was predominantly using forms with my classes, and I'm not teaching this term. However, it's still a disappointment.

The other issue I face is document editing. On my previous Nextcloud instance I installed the Collabora app and the built-in CODE server. That system promises to allow for document editing -- even collaboratively. However, typing in it is really laggy.

So, on the new server, I beefed up the RAM and CPUs a bit on the theory that it would run better. But run better it does not. Typing is still laggy (on Firefox and on Chromium) so that's too bad.

However, my understanding is that performance will improve with a separate CODE server. I will investigate this later. I would really, really like to be able to share a document with collaborators and edit it, rather than defaulting to a shared Google Doc (or even a pad-based document hosted somewhere else). But that's going to have to happen later.

The Why: Digital Sovereignty?

You might be thinking: why do this? I had an operating Nextcloud server -- why migrate?

I did this migration to move away from Digital Ocean, not because I don't like Digital Ocean -- I've been using their services for years, and I have paid for it with research funds because it has been central infrastructure for my work. I've learned a great deal from running things on Digital Ocean -- their tutorials are excellent.

I'm leaving Digital Ocean because it is a US-based company. I'm now in Canada. That means I'm paying Digital Ocean with research funds, which means I have been transferring Canadian public money to a US-based company. That does not sit right with me.

Instead, I shifted to the Digital Research Alliance of Canada. Digital Research Alliance is a non-profit organization running infrastructure for Canadian academics. It's free to use for Canadian faculty members, so I won't have to send research funds their way. But even if I had to pay, at least I'd be sending money to a Canadian organization.

Canada is having a major moment of reckoning -- the actions of Trump have led Canadians to think about sovereignty. That's a complex term and I won't unpack it here (though I am pondering it), but I will say that part of what I do -- in fact, a major reason for this very blog to exist -- is to think about the sorts of tools I use, where they come from, and where my data goes. So it makes total sense to migrate my research infrastructure away from US-based companies to a Canadian-based public service.

All that said, what's unclear to me is how Canadian the Digital Research Alliance infrastructure truly is. The organization is indeed based in Canada, with servers located at places such as the University of Waterloo. However, I know for a fact their website relies on Google code. The dominance of Amazon means that very likely the Alliance's server infrastructure relies to some extent on AWS -- and if not Amazon, perhaps Microsoft. I can't say for certain -- I need to learn more.

This is all muddied, of course, by the loose use of "sovereignty," where the term can even include Microsoft and OpenAI. It's hard to find clarity when it comes to questions of technological sovereignty.

Still I think what I've done is a net win. At the very least, a major part of my research expenditure is not going to a US firm, and my data is sitting physically in Canadian servers now. As is the case with many aspects of technological infrastructure, small steps are the ones we can and must take.