Can I move from closed testing to production in the same release?

Can I switch from closed testing to production without starting a brand new release

Yes. Google Play lets you reuse the same app bundle or APK that you tested in a closed track and roll it out to production, but production is still a separate release target in Play Console. The build can stay the same, the track changes.

A release in Play Console is the version you prepare for a track. Google documents that you can create a release on closed testing, open testing, internal testing, or production, and that production has its own release page. In practice, that means the file you tested does not need to be rebuilt just because you move it.

The part people get wrong is mixing up the build with the release. The build is the artifact you uploaded. The release is how Play Console serves that artifact to a track. A closed test can prove the build is ready, then you create a production release that points to the same build.

For a personal developer account created after November 13, 2023, the closed test gate is separate from the production rollout. Google says you must have at least 12 testers opted in continuously for the last 14 days before you can apply for production access. That is a requirement for access, not a requirement to rewrite the app.

The inconvenient part is that closed testing alone does not unlock production. You do not get to skip the production step just because the build already ran in closed testing. After the test requirement is satisfied, you still apply for production access, answer Google’s questions, and then create the production release.

If your closed test is already on the exact build you want to ship, you can usually promote that build instead of uploading a different one. That saves time and keeps your tested artifact intact. If you change code, resources, or the bundle after the closed test, then you are no longer shipping the same release artifact.

A simple example makes the distinction clear. You upload version 42 to a closed test, 12 testers opt in, and they stay opted in for 14 continuous days. After that, you apply for production access and create a production release using version 42. The app is the same version, the destination track is different.

If your Play Console shows no production access yet, the answer stays no for now. You can have a perfectly valid closed test and still be blocked from production until Google approves access. The release is not missing, the permission to publish is.

If you already have production access, the path is straightforward: open the Production track in Play Console, create a production release, and select the tested build. Google’s release flow also says you can edit an existing release instead of starting over, which is useful when you are changing notes or rollout settings rather than the build itself.

There is one more detail worth keeping separate. Internal testing does not count toward the closed testing requirement, and buying testers or installs to clear the gate violates Google Play policy. The clean path is to use real testers on your own app, meet the closed test requirement, then promote the same build through the proper production flow.

DevConnect fits that workflow because the exchange happens on owned property, not on someone else’s platform. You test someone else’s app, they test yours, and you keep the release process inside Google Play’s rules. If you want the platform side of that flow, the starting point is https://devconnectplatform.com.

The shortest accurate version is this: you do not need a brand new app build, but you do need a production release. Closed testing gets the build validated. Production is the separate step that makes it public.

In day-to-day work, that usually means you keep the same bundle, reuse the same release notes where they still fit, and change only the destination track and rollout settings. When launch fails, the usual cause is not the file. It is missing production access, an unfinished closed test, or an unpublished change blocking the release queue.