Domain Name Change: A Retrospective

I changed my name.

Well, not me personally, but the application I've been building and maintaining has changed its name and is now hakanai.io.

This isn't my first time working on a rebrand. I'm one of the co-founders of Malt, and Malt wasn't always called Malt.

The previous name was Hopwork.

A little game for you: if you can figure out the connection between Hopwork and Malt (there is one), feel free to mention it in the comments :)

I've learned a few things along the way, and I realized I hadn't written about this experience yet, so here's my chance.

Why Change Your Name?

Before we start, it's a fair question: why change your name?

Rebranding is a massive effort, and above all, it's a huge risk of losing current users or wasting the work you've already done to build awareness for your previous brand.

So I'll say it right away: you need solid reasons.

In Hopwork's case, there were several triggers.

First, Hopwork isn't an easy name for French speakers (or Spanish speakers, for that matter) to pronounce. And if your audience can't pronounce your brand, they're unlikely to remember it.

Second problem: there was confusion with Upwork, which is an American freelance platform. Unfortunately, Upwork was formed from the merger of two older companies, Odesk and Elance, and they adopted the Upwork name in 2015 without considering that we had existed since 2012.

It's pretty complicated when your brand is similar to that of a major American competitor, especially when most people don't know how to pronounce or write it.

I'll just say we had some discussions with this famous competitor on the subject. Since, well, we were there first. I can't say much more. But we decided to change our name, with some financial contribution from them.

In short, we decided to find a new name: short, easy to pronounce in all languages, and one on which we could rebuild an identity. And it became: Malt.

For Hakanai, it's a bit different, and I made some mistakes.

The product was initially called Blogtally, a name I chose in January 2025 to suggest an analytics tool ("Tally" meaning "count" in English). I later merged Blogtally with another product I created in 2024: RssFeedPulse.

But after two months, I realized that Blogtally wasn't showing up at all in SEO because the name was too close to tally.so and tally.xyz, and therefore to their blogs.

When you type your brand name and Google suggests it's a spelling mistake, you're off to a bad start...

I wasn't particularly in love with the first name I'd chosen anyway, but at this point, it was clear: I needed to change the name, and I chose Hakanai.io.

Create a Plan

Making the decision to change and finding the new name are the first steps. From there, you need a plan.

With hakanai.io, I work alone, but I still built a detailed checklist because even the smallest error can result in emails not being sent, incorrect invoices, broken links in emails, etc.

At Malt, we were "only" about fifty people in 2017 during the rebrand, but the risks were much greater.

But ultimately, even if the list varies, one principle always remains the same:

don't break the web

The Tech Corner

What do I mean by "don't break the web"?

I don't remember the first time I heard this expression, but I recall that Jean Baptiste Lemée (also a co-founder of Malt) used to repeat it often.

To simplify, the web is a set of resources linked together by hypertext links.

If you change a link, you need to ensure everything continues to work, so you need strategies to fix the links: redirects, modifications, compatibility, etc.

Obviously, this is very simplistic, since in the rest of this article we'll talk about branding, email, and all sorts of topics that aren't links. But this phrase is an idiom: a combination of words whose meaning doesn't directly follow from the literal meaning of each word.

Now, let's make a small list of what needs to be changed, with the strategy to adopt:

Domain Names

This is the most obvious. Migration will require a permanent redirect (301).

The "higher" the redirect is made, the more effective it is. For example, with Cloudflare, it can be done at the "Redirect Rules" level. But you can also do it at your web frontend level (apache, nginx, etc.).

If the site keeps the same architecture (the same URLs below the root domain), the redirect is extremely simple to do.

But if you're taking the opportunity to make structural changes, then you'll need to go through your web frontend and list each page with its new destination. Every link referenced on the internet must redirect to its current equivalent.

SEO

SEO is related to the previous point. Once you change your domain name, all the SEO you've managed to build on your old domain is "lost."

Fortunately, it's not permanent, and some will be regained with your redirects.

However:

• Major search engines will take time to understand the operation.
• You lose the bonus of your domain's seniority (its age)
• You have thousands of backlinks (links to your site) pointing to the old domain.

For backlinks, it's advisable to hunt down the most important ones and contact those sites to ask them to correct the links. There's no guarantee you'll succeed, though. And it's for reasons like this that your redirects will likely last a very, very long time.

Emails

Email is a big category since we have several possible problem areas:

• Sending emails

You'll need to go through all external services (Mailgun, Sendgrid, Mailchimp, etc.) that you use to reconfigure them with your new domain (SPF, DKIM, MX, DMARC, BIMI).

For this, you don't have to keep the old settings on your old domain, but making an exhaustive list is sometimes more complex than expected. With Hakanai it was pretty easy, but with Malt, you can't imagine the number of services we forgot after a few years that depend on this (like an old marketing tool that connects to send nurturing emails).

• Receiving emails

Changing your brand means changing your email. Your old email hugo@hopwork.com becomes hugo@malt.com, and you can hardly afford to lose emails sent to your old address.

Most business solutions allow you to manage professional domains and aliases to keep both domains in parallel.

For Hakanai, for example, I use Proton, and I have the ability to manage both domains. All emails arrive in my Proton mailbox.

The Code

Not surprisingly, you probably have references to your old name in your own code and various configuration files.

I strongly advise against a massive search/replace because some changes can have unexpected impacts.

For example, let's say you use package names with your name, like com.hopwork, and you decide to change everything.

First, a textual search and replace won't work since you also need to change the directory name.

But even in that case, you sometimes have objects that might be serialized in a database, sessions, caches, etc., that won't tolerate the change.

To be honest, I've often kept the old package names. It's invisible to everyone, and the effort isn't always worth it.

At Malt, we still have com.hopwork packages and even older packages with the name chosen during the prototype phase :)

As for configurations, it's up to you to see what they refer to. Sometimes they're linked to namespaces, on an Elasticsearch index. Sometimes it's an identifier that's used in an external tool.

So again, the change isn't necessarily trivial to make and can wait depending on the case.

Which is clearly not the case for the following points.

Regulatory Compliance

Migrating a name has a strong impact on regulatory matters, and unfortunately, it's not the fun part.

I'm not telling you anything new, your name is present in your terms of service and on your invoices.

So there's work to update all the "legal" documents on your site, ToS, privacy policy, which remains relatively simple.

In theory, this means getting users to accept the ToS again.

You can use the email that serves to notify your users of the name change to address this.

The problem can be everything else, like your invoices. Old invoices must remain unchanged, still referencing your old name. New ones must be modified.

Sometimes this might require, as with Malt, getting certain authorizations re-signed (like the billing mandate).

I won't dwell on the subject because it's very specific to each product. But it can prove to be long and tedious (and costly when going through law firms).

Brand Identity

All the previous chapters were actually pretty simple because they were technical. But the greatest difficulty is brand identity.

For example, with Malt, even today I still have people who talk to me about Hopwork. It's becoming increasingly rare, but it still happens.

Since the brand was born in 2012, it takes almost the same duration to eliminate the reflex.

You may have launched online ads, or even physical advertising campaigns, you may have old videos that talk about you with your old name. All of that is "lost."

A rebrand must be accompanied by a major communication effort to make your brand known again.

Conclusion

Changing your brand is hard, but that doesn't mean you shouldn't do it. During the change from Hopwork to Malt, we did, for example, an enormous amount of communication around this change, and the Malt name helped us grow.

I know it can be difficult to admit that a name can play a role in a company's development, and yet, I guarantee you that having a brand name that's easy to remember in multiple languages is a real advantage.

In the case of Hakanai/Blogtally, conversely, staying with a name that will always be overshadowed by another stronger brand could be a huge hindrance.

However, it's important to understand that the work continues long after the effective change:

• by monitoring traffic volume
• by trying to get backlinks corrected
• by identifying all errors that might persist (legal documents, redirects, emails, etc.)
• by redoubling efforts on brand identity.

That's it for now. I've tried to remember the most important things. But of course, if you see anything that should be part of this blog post, please let me know.

See you soon