Linux Phone Migration Rehearsal
Before switching to a Linux phone, rehearse critical workflows such as banking, navigation, and verification codes to see exactly what will break.
People moving from Android to a Linux phone often discover only after migrating that bank verification, transit cards, work logins, or photo backup no longer work. They first import their app list and a one-week usage summary, then flag activities that absolutely cannot be interrupted, such as receiving verification codes, tapping in for a commute, sharing their location with family, or logging into a work account.
Rather than looking for replacements by app name alone, the product breaks everyday activities into complete workflows. Users can rehearse each one: moving from a payment screen to bank verification, opening maps to start navigation, automatically backing up a photo after taking it, or logging into a company system after receiving a two-factor authentication text. Each workflow shows the actual path on a Linux phone, a workaround requiring an additional device, or a blocker with no viable alternative yet.
After the rehearsal, users receive a green, yellow, and red migration map. Green items can move on switch-over day; yellow items include steps to install, export, or keep the old phone; red items identify the service and verification method causing the block. The product also sequences the switch based on dependencies—for example, moving the authenticator and contacts before changing the primary SIM and payment services.
This version focuses on mainstream Linux phone operating systems and data users actively export. It will not flash devices or bypass bank and carrier security restrictions. The goal is a realistic pre-switch rehearsal: to show whether someone is merely changing phones or losing a capability they rely on every day.
Why now
When observed on August 6, the article about switching to a Linux phone ranked seventh in Hacker News’s new submissions feed, with 180 points and 150 comments. S1 The discussion directly surfaced practical obstacles such as banking apps, increasing the need for people planning a switch to verify critical workflows in advance. S1
Target user
People who have chosen a Linux phone and are preparing to retire their primary Android device. In the days before switching, they suddenly need to check banking, commuting, work access, and family communication. The device is already purchased, so the cost of backing out is rising. They do not need app recommendations; they need a personal interruption list that tells them whether to keep the old phone.
Minimal entry point
Users can export installed app package names with ADB package-manager commands, then upload a text file or CSV. S2 The initial one-week usage summary comes from a user-exported file or manual entry, with no persistent permissions requested. The backend maps apps to workflow templates such as payments, navigation, verification, and backup. Device capabilities draw on public information for Ubuntu Touch and similar systems. S3 Android compatibility paths reference Waydroid’s published limitations. S4 The first version uses rules and manual confirmation; it does not claim to remotely verify bank or carrier services.
Punching above its weight
The first users are already in this Hacker News discussion and Linux phone communities. S1 Publish anonymous migration-rehearsal templates that let commenters submit failed workflows and device-specific differences. Each public template links back to an editable personal version. Then turn recurring blockers into dedicated pages on bank verification, commuting, and work login to capture specific pre-migration searches.
Competitors & gaps
- Ubuntu Touch Device CatalogGoogle
- The Ubuntu Touch Device Catalog already lists device models, installation methods, and feature status, making it useful for an initial check of whether a target phone can boot and function normally. S3 It also tells users to verify the features they need and notes that some models may have connectivity issues. S3 But its unit of assessment is still the hardware feature. It does not read a personal app list or ask which activities cannot be interrupted. A working camera does not mean photos will back up automatically; working SMS does not mean a company-login flow will succeed. Users still have to translate feature status into everyday consequences. A migration rehearsal can handle that step while retaining the catalog as underlying evidence.
- Waydroid and individual APK installsGoogle
- Waydroid can already run an Android container on GNU/Linux and supports installing, listing, and launching Android apps. S4 That gives users without a native client a direct workaround. Ubuntu Touch documentation also clearly lists its limitations. S4 Banking apps that require Play Integrity or SafetyNet are unlikely to run. S4 Battery drain and contention with peripherals can create further problems. S4 Installing APKs one by one only shows whether an app opens. It cannot confirm that a payment redirect, verification-code entry, and photo backup work together as a complete flow. The opportunity for a migration rehearsal is to organize tests in advance and consolidate failure points, workarounds, and dependencies on the old phone.
How it makes money
Charge per migration project. The paid version generates a personal workflow map, switch-over sequence, and old-phone retention checklist, with compatibility-change alerts during the migration.
The case against
Compatibility conclusions can change easily with device model, region, and server-side policy. Bank verification is especially difficult to reproduce reliably, and account status also affects outcomes. A one-time success can be wrongly labeled as dependable long-term support; an inaccurate green result would directly undermine trust. Real testing also touches app lists, usage summaries, and work-account information, so privacy handling must be restrained. The workflow library needs continuous retesting as well. Without repeatable verification evidence, the product becomes little more than a better-organized forum checklist.