# Moving rules from production branch after Blueprint import **URL:** \ **Category:** Blueprint and App Design\ **Created:** [February 16, 2026, 11:59am UTC](https://forums.pega.com/t/moving-rules-from-production-branch-after-blueprint-import/10745 "2026-02-16T11:59:59Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![HalynaK2](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/halynak2/32/22468_2.png) [@HalynaK2](https://forums.pega.com/u/HalynaK2)\ **Post date:** [February 16, 2026, 11:59am UTC](https://forums.pega.com/t/moving-rules-from-production-branch-after-blueprint-import/10745/1 "2026-02-16T11:59:59Z")
I have a question regarding the Blueprint import process. When I import a Blueprint into the Pega platform, all the generated rules are saved in a branch of the production application. After importing the Blueprint and creating the required rulesets and the development application, what would be the recommended and best-practice procedure to move or merge the rules from the production branch into the development application? We want to ensure we follow the correct approach from a governance and deployment perspective. Thank you in advance for your guidance. ---
**Author:** ![Giovani](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/giovani/32/11769_2.png) [@Giovani](https://forums.pega.com/u/Giovani)\ **Post date:** [February 17, 2026, 3:33pm UTC](https://forums.pega.com/t/moving-rules-from-production-branch-after-blueprint-import/10745/2 "2026-02-17T15:33:26Z")
Hi @HalynaK2, First, I like to clarify that when you say Production Application it is the Target application on development environment? I mean because we shall import the blueprint on Development environment. From my perspective, once the Blueprint is imported into the target application, the recommended approach is to treat the generated rules like any other development artifact and follow standard branch‑based best practices. Specifically: - After the Blueprint import, add this branch to the **development application** where further refinement, extension, and validation will occur. - At this stage, you can **remove the branch reference from the target application** (without deleting the rules themselves), ensuring the target app remains stable and clean. From there, teams can continue working on the Blueprint‑generated rules in the development application, iterating as needed to reach **high‑fidelity alignment** with business requirements. This includes refining case life cycles, data models, views, and integrations beyond what Blueprint initially generates. Once the changes are fully implemented, tested, and validated, the branch can be **merged back into the target application** , following the same governance, testing, and deployment standards used for any other development work. In summary, Blueprint import is best viewed as an **accelerator for initial design and structure** , not a shortcut around established development practices. Managing Blueprint rules through branches and merges ensures traceability, quality, and consistency across environments. References: > **[Best practices for branch-based development | Pega Academy](https://academy.pega.com/topic/best-practices-branch-based-development/v1)** [https://academy.pega.com/topic/application-development-best-practices/v1](https://academy.pega.com/topic/application-development-best-practices/v1)? [Pegasystems Documentation](https://docs.pega.com/bundle/platform/page/platform/app-dev/branches-branch-rulesets.html) ---
**Author:** ![HalynaK2](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/halynak2/32/22468_2.png) [@HalynaK2](https://forums.pega.com/u/HalynaK2)\ **Post date:** [February 17, 2026, 5:34pm UTC](https://forums.pega.com/t/moving-rules-from-production-branch-after-blueprint-import/10745/3 "2026-02-17T17:34:30Z")
@Giovani Thank you for the clarification — yes, I was indeed referring to the **target application**. I also noticed that in the class structure generated during the Blueprint import, for the Integration layer classes, the system creates the class under **Org-App-Data** instead of **Org-App-Int**. I wanted to confirm whether this is expected behavior or if it requires any adjustment for following our standard layering conventions. Thank you again for your guidance. ---
**Author:** ![Giovani](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/giovani/32/11769_2.png) [@Giovani](https://forums.pega.com/u/Giovani)\ **Post date:** [February 17, 2026, 6:13pm UTC](https://forums.pega.com/t/moving-rules-from-production-branch-after-blueprint-import/10745/4 "2026-02-17T18:13:56Z")
@HalynaK2 Yes, this is **expected behavior** with Blueprint import. During the Blueprint import, the system creates **Data classes under `Org-App-Data`** , even for objects that conceptually represent integrations. This is intentional and aligns with the role Blueprint plays in the lifecycle. Blueprint focuses on establishing a **design‑time starting point** to support: - Case structure - Data model - View/UI pre‑visualization - End‑to‑end flow understanding At this stage, Blueprint generates **data objects only** , primarily to support UI rendering, relationships, and case logic validation. It does **not** attempt to model the full integration architecture. This is different from using the **Integration wizard** , which explicitly creates: - `Org-App-Int-*` classes to represent the external system model - Separate Data classes to map external structures into the internal Pega data model With Blueprint, the assumption is that teams will **evolve the application after import**. As part of that evolution, it is expected that architects: - Introduce proper `Org-App-Int-*` classes when implementing real integrations - Refactor or extend the generated Data classes as needed - Apply standard layering and integration best practices during implementation So in short, Blueprint intentionally creates a **simplified data-centric model** to accelerate design and validation, with the expectation that some **rework and refinement** will occur once development moves beyond Blueprint and into full implementation. ---
**Author:** ![HalynaK2](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/halynak2/32/22468_2.png) [@HalynaK2](https://forums.pega.com/u/HalynaK2)\ **Post date:** [February 18, 2026, 12:22am UTC](https://forums.pega.com/t/moving-rules-from-production-branch-after-blueprint-import/10745/5 "2026-02-18T00:22:27Z")
@Giovani Hi, thank you for your response. I’m now encountering another issue: after importing the Blueprint into the target application and creating Dev and Test applications, all of them show the warning **“Unlock application ruleset to update routing table.”** The rulesets in the stack are already unlocked, but the platform still seems unable to detect a writable ruleset for the Routing Table. Could you advise what might be causing this? ---
**Author:** ![Giovani](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/giovani/32/11769_2.png) [@Giovani](https://forums.pega.com/u/Giovani)\ **Post date:** [February 18, 2026, 3:54pm UTC](https://forums.pega.com/t/moving-rules-from-production-branch-after-blueprint-import/10745/6 "2026-02-18T15:54:05Z")
Hi @HalynaK2, Did you switched on your “Brach development preferences”? If not, follow these steps, 1. Click “Toggle branch development” icon 2. Turn on Branch development 3. Select your development branch. > **[Pegasystems Documentation](https://docs.pega.com/bundle/platform/page/platform/app-dev/setting-branch-development-preferences.html)** ---
**Author:** ![HalynaK2](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/halynak2/32/22468_2.png) [@HalynaK2](https://forums.pega.com/u/HalynaK2)\ **Post date:** [February 18, 2026, 8:07pm UTC](https://forums.pega.com/t/moving-rules-from-production-branch-after-blueprint-import/10745/7 "2026-02-18T20:07:57Z")
@GiovaniThanks a lot for the suggestion — turning on Branch development and selecting the branch solved the issue. Appreciate the help!