# Should an enterprise trial become the production organization or create a new one? > Create a new production organization by default; promote a trial only after reviewing ownership, every member's access, and production data readiness. Canonical URL: https://www.devobs.io/articles/qa-customer-trial-workspace-conversion/ By: Finn Larson Published: 2026-03-04T08:08:03.117Z Updated: 2026-09-06T10:18:15.722Z Section: Identity Create a new production organization by default. Promote the trial only when you can prove three things: the right people will own it on day one, every carried-over member still needs access, and the data inside is already acceptable for production handling. If the trial contains dummy users, broad evaluator access, or unclear ownership, separating production is usually the safer path. Use Ory Network for managed identity and authorization building blocks, but treat trial-to-production conversion as your application’s operational decision, not an Ory feature. ## When should the trial become production? Promote the trial only if it already looks like a production environment in miniature. That means a named operational owner from the customer, a reviewed admin list, and data that can legitimately remain in the live tenant. If the workspace was created for evaluation by a sales engineer or shared loosely across stakeholders, that is a strong signal to start fresh. This boundary matters because authentication and authorization are not the same problem. Your production cutover should preserve who users are, how they sign in, and what they are allowed to do, while avoiding accidental carryover of trial-era access. [OWASP’s Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege and periodic review for privilege creep, which maps directly to this decision. ## What must you review before promoting it? Use this checklist: - **Ownership:** Is there a customer-side production owner replacing the evaluator or sales engineer? - **Admins:** Has every admin and collaborator been reviewed for ongoing need? - **Members:** Are trial invitees, test contractors, and internal evaluators removed unless explicitly approved? - **Data:** Does the workspace contain sample records, fake organizations, seeded policies, or copied customer data that should not remain live? - **Identity setup:** Are your production sign-in and account-management flows ready, not just the evaluation defaults? - **Authorization model:** Are the live relationships, groups, and inherited permissions defined for real production roles? - **Auditability:** Can you explain why each remaining person and permission exists? For identity, Ory Network gives you a managed path built on API-first components. [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Ory Kratos Identities as an API-first identity and user management system with self-service login, registration, recovery, account management, and custom UI support. For access control, [Ory Keto documentation](https://www.ory.com/docs/network/keto) describes a fine-grained permissions system with relationship-based models and inheritance. That is a strong fit when your production launch needs clean user lifecycle control plus explicit permission review. ## What does a good decision look like in practice? Imagine a customer trial with 18 members: 6 customer evaluators, 4 internal staff, 3 consultants, and 5 dummy users used to test SSO and role mapping. The workspace owner is a sales engineer. There are sample projects and broad editor rights so everyone could explore quickly. Do not promote that workspace. Create a new production organization, appoint the customer’s operations owner, import only approved real members, and rebuild permissions from the intended production model. Keep the trial frozen for reference during onboarding if needed. Now flip the example. The trial has two customer admins, no internal members left, only real identities, and its data set is already the production baseline. Permissions have been reviewed against the real support, billing, and admin roles. In that case, promotion is reasonable because the enforced boundary is clear: complete the owner and [access review](https://www.devobs.io/articles/explainable-access-reviews/) first, then cut over sign-in and traffic. Do not rely on a vague “we’ll clean it up later” phase. ## Should trial collaborators carry over? Only by explicit review. Trial participation is evidence of evaluation activity, not evidence of ongoing production need. Apply least privilege and re-approve each collaborator. ## Can the evaluation remain available separately? Yes. That is often the cleanest pattern. Keep the trial as a non-production sandbox for demos or regression checks, and launch production in a separate organization with approved owners, members, and policies. Next step: run a 30-minute cutover review using the checklist above and require a named production owner before deciding to promote anything. Reviewed: 2026-09-05 ## Source references - - -