How do you approach a major platform migration, like moving a large app to Jetpack Compose?

#What the interviewer is really probing

When someone asks how you'd approach a migration like this, they aren't testing whether you know Compose's mental model — that's a separate technical question. They're testing whether you think about migrations as an organizational and risk-management problem before you think about them as a technical one. A weak answer describes screens; a strong answer describes sequencing, a rollback path, how the team keeps shipping features on the old stack while the new one comes online, and how you'd measure whether the migration is actually paying for itself. That's the shape I try to land on within the first thirty seconds of the answer, because it signals seniority faster than any framework trivia does.

#Audit before you announce anything

The first thing I actually do — before a single line of Compose ships — is build an honest inventory of the app: how many screens, which ones are high-traffic vs. rarely touched, which ones sit on custom Views with years of undocumented edge cases, which ones a junior engineer could safely tackle versus which ones only the two people who understand the checkout flow should go near. I categorize by a simple grid: business risk if it breaks, and technical complexity to convert. That map is what turns "we should migrate to Compose" from a slogan into a plan, and it's usually the artifact that gets a skeptical VP of Engineering to say yes, because it shows you've already thought about what could go wrong.

#Pick a beachhead with the strangler-fig pattern

I never propose rewriting the app in one pass — that's the single most common way these efforts die, because a big-bang rewrite means the business gets zero incremental value for however many quarters it takes, and any slip becomes an existential argument against the whole initiative. Instead I use the strangler-fig approach: wrap a handful of low-risk, self-contained screens in Compose first — a settings screen, a profile screen, something with real users but low blast radius — using ComposeView to host them inside the existing Activity/Fragment shell, and AndroidView in reverse whenever a not-yet-migrated custom View needs to sit inside a newly Compose-first screen. That interop layer is not a hack; it's the entire mechanism that lets both worlds coexist for the year or two a real migration actually takes.

#Make the business case with numbers, not conviction

Engineers get excited about Compose's declarative model; engineering directors get excited about evidence. So I treat the first pilot screens as an experiment with instrumentation: build time impact, APK size delta, crash-free rate before and after, and — the number that actually moves budget conversations — how long a comparable feature took to build and QA on the old stack versus the new one. Once you can say "the settings rewrite took thirty percent less calendar time and needed half the manual QA passes because we could preview and screenshot-test the UI without running the emulator," you've turned an aesthetic preference into a funded initiative.

#Build the muscle before you scale the effort

A migration that depends on two Compose-literate engineers doesn't scale past those two people. In parallel with the pilot, I invest in a shared component library — the buttons, cards, and layout primitives the whole team will reach for — so the fifth engineer to touch Compose is assembling from vetted pieces, not re-deriving stability and state-hoisting rules from scratch. I pair deliberately, run short internal workshops on the traps that bite everyone once — unstable list parameters, remembering the wrong things, recomposition surprises — and I make code review the enforcement mechanism for the patterns we've agreed on, rather than relying on tribal memory.

#Guardrails that keep the app shippable the whole time

Every migrated screen ships behind a feature flag and rolls out to a small percentage of production first, because Compose changes rendering, and the failure mode you're guarding against is a subtle visual regression or a Compose-specific performance regression — jank on a low-end device — that never shows up on your team's flagship test phones. I keep baseline profiles and startup/frame-timing benchmarks in CI so a regression is caught before it merges, not after a support ticket surfaces it, and I keep an explicit rollback lever — kill the flag, fall back to the View — for every migrated screen for at least one release cycle.

#How I'd tell this story in an interview

If I've actually led one of these, I anchor the answer in a specific screen, a specific metric, and a specific moment where the plan needed to bend — a performance regression we caught in canary, a stakeholder who wanted to skip the pilot and go straight to the home screen, a junior engineer who needed more pairing than I'd budgeted for. Interviewers remember migrations described as a negotiated, measured process a lot more than they remember a clean, conflict-free story — the friction is what proves you actually ran one.