DEV Community

ahfu168
ahfu168

Posted on

What I Learned Migrating an Android App to a New Brand and Domain

#android #mobile #software

Renaming an existing app turned out to be much more than changing a logo and a store title.

When we moved our product from Song Flow to MiraYola, we had to deal with several systems that had already formed assumptions around the old brand:

  • Android package identity
  • Deep links
  • Website domains
  • Google Play App Links verification
  • Canonical URLs
  • Old shared links
  • Google Search Console
  • Third-party pages that still referenced the old name

The most important lesson was that a brand migration is really an infrastructure migration.

This post covers the parts that caused the most uncertainty and the decisions that helped us avoid breaking existing users.

1. Keep the Android package name stable

The Android app already used:

com.huoji.singflow
Enter fullscreen mode Exit fullscreen mode

The public product name changed, but we intentionally kept the package name.

For an existing Google Play app, the package identifier is part of the application's technical identity. Changing it would effectively mean publishing a different application.

That would create unnecessary problems around:

  • Existing installs
  • Store history
  • Purchases
  • Deep links
  • Update continuity

So our setup became:

Public brand: MiraYola
Android package: com.huoji.singflow
Website: mirayola.huoji.app
Enter fullscreen mode Exit fullscreen mode

It looks inconsistent, but technically it is completely reasonable.

A public brand name and an internal package identifier do not need to match.

2. Decide what the root URL should represent

The website supports multiple languages:

/en
/zh
/ja
/ko
/ar
Enter fullscreen mode Exit fullscreen mode

We did not want both:

/
Enter fullscreen mode Exit fullscreen mode

and:

/en
Enter fullscreen mode Exit fullscreen mode

to behave like duplicate English homepages.

So the root URL permanently redirects to the English version:

/ → /en
Enter fullscreen mode Exit fullscreen mode

The English page then declares itself as canonical.

A simplified example:

<link
  rel="canonical"
  href="https://mirayola.huoji.app/en"
/>
Enter fullscreen mode Exit fullscreen mode

This gave search engines one clear English homepage instead of two competing URLs.

3. Do not panic when Search Console lags behind production

During the migration, Google Search Console temporarily reported the root page as:

Page is not indexed: Redirect error
Enter fullscreen mode Exit fullscreen mode

The first instinct is to assume the current routing is broken.

Instead, we checked the real HTTP behavior:

curl -IL https://mirayola.huoji.app/
Enter fullscreen mode Exit fullscreen mode

The expected flow was:

308
Location: /en
Enter fullscreen mode Exit fullscreen mode

followed by:

200
Enter fullscreen mode Exit fullscreen mode

on the destination page.

The production behavior was already correct, while Search Console was still reflecting an earlier crawl.

After Google crawled the site again, the status changed.

That was a useful reminder:

Search Console is not always a real-time representation of production.

During migrations, I now verify both:

  1. The actual HTTP response
  2. The latest Google crawl state

before changing routing again.

4. SEO pages and App Links should not be the same thing

One of the most useful decisions was to avoid making the entire website open inside the Android app.

Pages such as:

/en
/en/features/ai-song-generator
/en/plaza
Enter fullscreen mode Exit fullscreen mode

are normal web pages.

They should stay accessible in the browser.

But URLs representing interactive app content, such as:

/room/*
Enter fullscreen mode Exit fullscreen mode

are good candidates for Android App Links.

So the model became:

Informational / SEO pages
→ Browser

Interactive app content
→ Android app
Enter fullscreen mode Exit fullscreen mode

This kept App Links focused instead of treating every web URL as an application route.

5. Configure the Android side with a narrow intent filter

A simplified intent filter looked like this:

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />

    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />

    <data
        android:scheme="https"
        android:host="mirayola.huoji.app"
        android:pathPrefix="/room/" />
</intent-filter>
Enter fullscreen mode Exit fullscreen mode

This tells Android that the application wants to handle URLs under:

https://mirayola.huoji.app/room/
Enter fullscreen mode Exit fullscreen mode

The important part is keeping the scope intentional.

Just because an app owns a domain does not mean every page on that domain should open the app.

6. Verify the relationship with assetlinks.json

The website also needs to authorize the Android application.

That happens through:

/.well-known/assetlinks.json
Enter fullscreen mode Exit fullscreen mode

A simplified example:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.huoji.singflow",
      "sha256_cert_fingerprints": [
        "PLAY_APP_SIGNING_SHA256"
      ]
    }
  }
]
Enter fullscreen mode Exit fullscreen mode

The most important detail here is the signing certificate.

For an app distributed through Google Play, the fingerprint used by production installations may be the Play App Signing certificate rather than the certificate used locally.

Using the wrong fingerprint can make the configuration look correct while verification still fails.

7. Keep the old domain alive during the transition

Old links do not disappear when a brand changes.

They may still exist in:

  • Old social posts
  • Chat messages
  • Bookmarks
  • Search indexes
  • Previously shared content

Instead of immediately removing the old Song Flow domain, we kept it available during the migration.

The new domain became the preferred destination:

mirayola.huoji.app
Enter fullscreen mode Exit fullscreen mode

while old links could continue working when necessary.

This was especially important for deep links.

A migration is much safer when new links move forward without forcing every old link to stop working on the same day.

8. Redirects and App Links solve different problems

This distinction helped simplify the architecture.

A redirect answers:

Which web URL should this web URL resolve to?

For example:

/ → /en
Enter fullscreen mode Exit fullscreen mode

An App Link answers:

Should Android open this HTTPS URL in the app?

For example:

/room/123 → Android app
Enter fullscreen mode Exit fullscreen mode

Those are separate layers.

Mixing them together makes debugging much harder.

9. The hardest part was not technical

Most of the technical changes can be verified quickly.

You can check:

  • HTTP responses
  • Canonical tags
  • assetlinks.json
  • Android intent filters
  • Google Play Deep Links verification

The harder part is that external systems update at different speeds.

After a rebrand:

  • The app store may show the new name immediately
  • Google Search may still show old information
  • Third-party directories may take longer
  • Old URLs may remain indexed for some time

That does not necessarily mean the migration is broken.

It often means the internet is gradually converging on the new identity.

What I would do differently next time

Before changing the public brand, I would make a migration checklist covering:

Domains
Android App Links
Deep links
Canonical URLs
App store metadata
Structured data
Social profiles
Shared URLs
Third-party listings
Search engine indexing
Enter fullscreen mode Exit fullscreen mode

I would also test all important URLs before and after the change.

A few simple commands can catch a surprising number of problems:

curl -I https://example.com/
curl -IL https://example.com/
curl https://example.com/.well-known/assetlinks.json
Enter fullscreen mode Exit fullscreen mode

And most importantly, I would avoid changing stable technical identifiers unless there is a real reason to do so.

The public brand can change.

The infrastructure does not always need to.

Final takeaway

The visible migration was simple:

Song Flow → MiraYola
Enter fullscreen mode Exit fullscreen mode

The actual migration involved:

Brand
+
Domain
+
Redirects
+
Canonical URLs
+
Android App Links
+
Deep Links
+
Backward compatibility
+
Search re-indexing
Enter fullscreen mode Exit fullscreen mode

That is the part of a rebrand users rarely see.

If you are planning a similar migration, my main advice is:

Treat the rename as an infrastructure change first, and a branding change second.

This post is based on the real migration of the MiraYola Android app and website.

AI-assisted disclosure: AI was used to help organize and edit this article. The technical decisions and migration details are based on the actual implementation.

Top comments (1)

Collapse
 
redirhub profile image
Redirhub •

The “keep the old domain alive” part is underrated. Old links have a way of surviving way longer than the migration itself