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
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
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
We did not want both:
/
and:
/en
to behave like duplicate English homepages.
So the root URL permanently redirects to the English version:
/ → /en
The English page then declares itself as canonical.
A simplified example:
<link
rel="canonical"
href="https://mirayola.huoji.app/en"
/>
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
The first instinct is to assume the current routing is broken.
Instead, we checked the real HTTP behavior:
curl -IL https://mirayola.huoji.app/
The expected flow was:
308
Location: /en
followed by:
200
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:
- The actual HTTP response
- 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
are normal web pages.
They should stay accessible in the browser.
But URLs representing interactive app content, such as:
/room/*
are good candidates for Android App Links.
So the model became:
Informational / SEO pages
→ Browser
Interactive app content
→ Android app
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>
This tells Android that the application wants to handle URLs under:
https://mirayola.huoji.app/room/
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
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"
]
}
}
]
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
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
An App Link answers:
Should Android open this HTTPS URL in the app?
For example:
/room/123 → Android app
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
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
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
The actual migration involved:
Brand
+
Domain
+
Redirects
+
Canonical URLs
+
Android App Links
+
Deep Links
+
Backward compatibility
+
Search re-indexing
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.
