After moving or cloning my WordPress site, the app stopped working

Goal

Here’s how to get your published mobile app talking to your WordPress site again after you’ve moved it to a new host, cloned production into staging (or staging back into production), or restored from a backup.

Your app itself never changes — it’s a compiled iOS/Android binary already sitting in the App Store and Google Play. What can change is the site it’s pointing at, plus a handful of values stored in your database that tie this WordPress install to your customer record on the WPMAM (Tiny Screen Labs) enrollment server. A migration can leave those values pointing at the wrong place. Below are the four most common causes, in the order you should check them.

Prerequisites

WordPress admin access (manage_options) on the site the app is supposed to talk to.
The site is reachable at its real public URL over HTTPS (not a temporary host preview URL or an IP address).
You know which install is meant to serve the live app: production, not staging. This matters — pointing the live app at a staging copy is the single most common post-migration failure.
Ideally, access to your hosting/SQL tools or a database plugin, in case you need to peek at a stored option value — though most steps can be done from the admin screens alone.

Background: what a migration can break

Four things tie your published app to this specific WordPress install, and a move, clone, or restore can knock any of them loose.

What	Where it lives	What goes wrong on a migration
Account code	The account-code option, owned by `MAM_Account_Code_Manager`.	A clone copies production’s account code into staging (or vice-versa), so two sites now claim the same code, or a site claims a code that belongs to a different customer.
Site URL	WordPress `siteurl` / `home`, read at runtime via `get_site_url()`.	The app was built with the API endpoint baked in at publish time. If the live site’s URL changed (new domain, `http`→`https`, `www` toggle), the app is still calling the old address.
Verification cache	A cached transient (`mam_account_code_verified`, refreshed at most once a day per site URL).	The Publish page may show yesterday’s comparison until the cache expires. It only reports; it never changes your code.
Credential paths	Publish/push settings keyed by account code on WPMAM’s side.	If the account code drifted, push and publish requests route against the wrong customer record on the server.

Think of the account code as a frozen contract: roughly 2,000 customer sites already have a value stored, every app references it, and the whole publish pipeline depends on it. Handle it carefully — your goal is to land the correct code on the correct site, not to invent a new one.

Steps

1. Confirm which site the app should be hitting

Start by opening Mobile App Manager → Publish App — it reads the site URL at runtime (get_site_url()), so whatever it shows reflects the install you’re actually logged into right now.

If you’re on staging and the live app is misbehaving, stop here — you almost certainly want to be on production. The app’s API endpoint was frozen into the build when you published; it points at the URL the site had at that moment.
Check that your production WordPress Settings → General shows the exact public URL — correct scheme, correct host, no leftover staging or host-preview domain. If it’s wrong, fix it here first and re-test the app before doing anything else.

If the app’s baked-in endpoint doesn’t match your live URL at all — say, you genuinely changed domains — no database edit here will fix it. The app needs a new build published so the new endpoint gets compiled in. Work through the remaining steps to get the site healthy, then re-publish.

2. Answer the “address changed” notice

After a move or a clone, Mobile App Manager shows an admin notice on the site whose address changed. It asks one question:

This site moved to a new address. Choose this on your live site after a domain move. The server moves your existing account to the new address and your account code stays the same.
This is a staging copy. Choose this on a copy of your live site. The copy gets its own staging account, linked to your production account, and switches to that account’s code. Production is not touched.

Nothing changes until you choose, and an error changes nothing. See Update your app when your site URL changes for details.

3. Check the Publish page

Open Mobile App Manager, Publish Your App. It compares this site’s account code with the code the server has on file for this site’s URL (cached for up to a day per URL).

No warning: the codes agree.
A yellow Account check warning: the codes differ. The page does not change your code; it only tells you. Publishing still uses this site’s own code. Contact support before you publish, and include both codes shown in the warning.

4. Keep the staging copy from fighting production

Answer the notice on the copy with This is a staging copy, so it stops using the production account code.
Make sure only the production install answers to the live public URL.
If you are unsure which install should own the live account, stop and contact support.

5. Re-verify push and publish credentials

Some credential paths — push notification routing, publish/Fastlane authentication — key off the account code on WPMAM’s side. Once the account code is correct on the live site:

Re-open Publish App and confirm the page no longer shows an account-code or subscription warning.
If push notifications had stopped working, have a test user log out and back in of the mobile app. Device push tokens live per-user as user meta — WordPress’s per-user custom-data store — and refresh on login, so signing back in re-registers the device against the now-correct backend. A clone that copied stale tokens between sites heals the same way: by logging back in from the real devices, not by editing the database.

6. Confirm app role/content cloning still works (if you use it)

If your workflow relies on admin cloning — previewing the app as another role — or on copying one role’s app content into another, give that a re-test after the migration. Both the “clone role content” admin action and the “view as role” preview run against your current install’s stored content, so the account code doesn’t touch them — but it’s easy to mistake one for a backend problem. If admin cloning works fine but real devices don’t, you’re looking at account-code/URL drift (steps 1–5), not a content issue.

How to tell it worked

Publish App loads with no Account check warning and no subscription warning.
The live site kept its account code after the move, and the staging copy has its own staging code.
A real device, after the user logs out and back in, loads app content and receives a test push.
Your staging/restored copy no longer holds the live account code (or is flagged as staging), so it can’t interfere.

When to stop and contact support

Open a support ticket rather than continuing to edit values if:

You don’t know which of two installs owns the live account code, or the Account check warning won’t go away.
You chose the wrong button on the address-changed notice, or the notice keeps returning an error.
Push or publish still routes to the wrong place after the account code looks correct — credential paths on the server may need re-pointing.

The account code is a frozen, customer-spanning contract — misrouting it can affect store submissions and push notifications for someone else’s account entirely. When in doubt, get it confirmed rather than reset.

Integration: Account code and enrollment server — the MAM_Account_Code_Manager API, the verification cache, and graceful degradation.
Recipe: Publish your app to iOS and Android — re-publishing a build after a domain change.
Recipe: Customer enrollment and account code — first-time enrollment and re-enrollment.