Data Packs: How To Remove Customisations During an Upgrade
If your project has been running for some time, it is likely that you have had to customize a Quantexa Data Pack to meet specific requirements. Historically, this required "forking" the Data Pack repository and maintaining your own version of the code. While this approach provided flexibility, it came at a significant cost: Increased Technical Debt: Your team became responsible for maintaining a growing fork of custom code. Higher Upgrade Effort: Every platform upgrade required you to manually migrate and re-test your forked Data Pack, a complex and time-consuming process. Missed Opportunities: Your forked version did not benefit from the continuous stream of new features, performance improvements, and bug fixes being added to the official Quantexa Data Pack releases. Starting with platform version 2.6, Fusion Extensibility provides a powerful new model that allows you to apply the most common customizations without forking the code. This is a fundamental shift that enables you to stay aligned with the official Data Pack releases while still meeting your unique project needs. For more details on this framework, see the official Fusion Extensibility documentation on the Documentation Site. The Opportunity: When to Migrate Your Customizations If your project is on version 2.6 or later and you are still maintaining a forked Data Pack, you have a strategic opportunity to eliminate this technical debt. However, because migrating from a fork to the official Data Pack will introduce significant (and desirable) changes to your ETL output, it is strongly recommended to treat this migration as a standalone project, separate from a major platform upgrade. Attempting to do both at the same time makes it extremely difficult to perform root cause analysis. If you see a change in your data, is it because of the platform upgrade or because of the Data Pack migration? By separating the two projects, you can isolate the variables and test each change independently, leading to a much smoother and lower-risk process. The Migration Process: From Fork to Extensibility The migration process involves a careful review and triage of every customization you have made. Step 1: Review Your Forked Data Pack Go through your forked repository's commit history and create a detailed list of every functional change you have made compared to the original Quantexa version. Step 2: Triage Each Customization For every single customization you have identified, you must now make a critical decision. Ask Yourself... If the answer is YES... If the answer is NO... 1. Is this customization achievable using the new Fusion Extensibility patterns? Great! Your action is to plan to re-implement it using the new model. Go to question 2. 2. Is this customization still a critical business requirement? Your action is to acknowledge that you must remain on your forked version for now. You should then raise an enhancement request in the Quantexa Product Roadmap to have this capability added to the core product in the future. This will unblock your migration later. Excellent! This is an opportunity to simplify. Your action is to plan to discard the customization and use the standard, out-of-the-box Data Pack functionality. Step 3: Execute Your Migration Plan Based on the outcome of your triage, your path is now clear: If all of your critical customizations can be achieved via extensibility or have been deemed no longer necessary, you can proceed with re-implementing them and decommissioning your forked repository. If even one critical customization cannot be achieved, you must pause the migration, raise the necessary enhancement requests, and continue to maintain your fork until the product supports your needs. The Testing Strategy: Focus on Intent, Not Identical Output This is the most critical concept to understand when testing your migrated Data Pack. You should NOT be testing for identical output. Your old, forked Data Pack is likely behind the latest official version. The new version contains numerous bug fixes, functional improvements, and performance enhancements that will naturally and correctly lead to different ETL output. Your testing strategy must instead focus on validating the intent of your original customizations. If your customization was to... Your new test should verify that... Add a new "Risk Score" derived field... The "Risk Score" field is still being correctly calculated and added to the model, even if other parts of the record have changed due to product improvements. Exclude compounds based on a specific pattern... The correct compounds are still being excluded based on your custom logic. Add a new "Source System ID" attribute to an Entity... The "Source System ID" attribute is still present on the resolved Entities with the correct value. By adopting this testing mindset, you embrace the benefits of the new Data Pack version while ensuring your critical business logic remains intact. The result is a dramatic reduction in custom code, a simpler and faster future upgrade path, and immediate access to the latest Quantexa features.How to Release Your Upgrade: Approaches and Considerations
You have successfully tested your upgrade and are now dev-complete. The final stage of the execution process is to plan and execute the merge of your upgrade branch back into the main codebase, making it the new standard for all future development. A smooth merge is the result of careful coordination and communication. This guide provides a step-by-step checklist to ensure your upgrade is integrated without disruption. Step 1: The Final Polish - Apply the Latest Patch Before you begin the sign-off and merge process, ensure you are integrating the best possible version of the software. It is strongly recommended to update your upgrade branch to the latest available minor version or patch for your target release (e.g., if you upgraded to v2.8.2, check if v2.8.3 is now available). These releases contain the latest bug fixes and security updates but no breaking changes, making them low-risk to apply. You can find instructions for this process in the documentation on applying a minor upgrade. Step 2: Gain Stakeholder Sign-Off Before planning the merge, you must get formal approval from all relevant stakeholders. Do not wait until the last minute for this; seek sign-off as soon as individual components are ready for review. Action: Secure approval from the following groups: Product Owners / Business Users: Present your UAT results and regression reports to demonstrate that the functionality is correct and performance is acceptable. Technical Leads / Architects: Get your code reviewed. Your Pull Requests should be approved well in advance of the target merge date to allow time for feedback and iteration. Downstream Consumers: If other teams or applications consume your project's APIs or data outputs, ensure they have been part of the testing and have signed off on the changes. Pro-Tip: If your ETL upgrade was completed first, get it reviewed and signed off while the rest of the upgrade is still being tested. Step 3: Prepare and Educate Your Users Proactive communication is key to a smooth transition for everyone involved with the project. Action: Prepare your user groups for the upcoming change. For Technical Users (Developers): Produce a clear changelog or technical release notes. Inform them of any changes to development environments, deployment strategies, or key data structures that will impact their day-to-day work once the merge is complete. For End-Users (Investigators, Analysts): Provide an updated user guide or release communication that documents any major changes to the User Interface (UI) or application functionality that they will see in the next production release. Step 4: Plan the Merge Logistics This step involves defining the precise technical strategy for merging your code. Action: Define your merge plan, considering project structure. For Split Repositories: Your merge plan must respect inter-repository dependencies. For example, a shared "model" repository must be merged, published, and consumed by the "ETL" and "Apps" repositories before they themselves can be merged. Document the exact order of operations. For Multi-Use Case Platforms: Refer back to your upgrade plan. Ensure that the merge of your upgraded use case will not negatively impact the build or development process for other use cases running on the same platform. Step 5: Coordinate and Execute the Merge to Main This is the final, coordinated event to integrate the upgrade into your main codebase. Action: Follow this checklist for a smooth merge: Set a Merge Date: Align with all development teams on a specific date and time for the merge. Communicate a Merge Freeze: Announce a "merge freeze" for the main branch leading up to the agreed-upon merge time. This prevents last-minute, unrelated changes from introducing conflicts or instability. Prepare a Rollback Strategy: Have a documented plan in place for how you would revert the merge commit (e.g., using git revert) in the unlikely event of a critical, unexpected issue post-merge. Execute the Merge: With all preparations in place, merge your feature/platform-upgrade branch into main. Post-Merge Communication: Announce to all technical teams that the merge is complete. All new feature development must now branch from the updated main branch. With the merge complete, your upgrade is now part of the main line of development. It will be deployed to production as part of your project's next standard release, following your organization's established release playbook.Testing Your Upgrade: Practical Considerations
You have successfully migrated your code to the target version, and you have a stable, building repository. Now, you will execute the Test Plan you created during the planning phase. This guide provides a practical, step-by-step methodology for development testing. The core principle is to start with fast, low-cost tests and progressively move to slower, more expensive, and more realistic validation. Do not jump straight to full data runs. Phase 1: The Foundation - Local and Automated Testing This is the fastest and most important feedback loop. The goal is to catch as many issues as possible on your local machine before ever deploying to a shared environment. Validate Automated Tests: Your first step is to ensure your existing automated test suite is working. Unit & Integration Tests: Run your entire suite of automated tests locally. Fix any failures. These tests are your first line of defense and are crucial for validating that core logic within your ETL and Scoring processes is still sound. Local Runtime Testing: Before deploying, try to run components locally. Example: Starting the Quantexa application services on your local machine can quickly reveal runtime dependency conflicts or configuration errors that were not caught at compile time. Fixing these locally is much faster than in a shared environment. Phase 2: Controlled Environment Testing Once your local tests are passing, it's time to move to a shared development or test environment. The goal here is to perform an initial end-to-end run in a controlled manner. Establish a Stable Baseline: To test for regression, you must have a stable point of comparison. Control Your Code: Ensure the main branch (your baseline) and your upgrade branch are based on the same starting commit. A common practice is to create a temporary release-candidate branch from main to use as a stable, unchanging baseline for comparison. Control Your Data: Use a static, well-understood dataset for this testing phase (e.g., a synthetic or a small, sanitized sample of real data). The input data for your baseline run and your upgrade run must be identical. Produce the Baseline Run: Execute your full end-to-end batch process on the main (or release-candidate) branch using your controlled dataset. Document the results meticulously. This includes: HDFS/S3 output locations. Elasticsearch index names. Batch job runtimes and resource profiles. Produce the Upgrade Run: Execute the same end-to-end batch process on your upgrade branch, using the exact same input data. Compare and Analyze: Compare the outputs from the upgrade run against your baseline. The Statistical Profile Testing Framework (SPTF) is the recommended tool for efficiently comparing batch outputs. Expect some changes. Bug fixes or functional improvements in the new Quantexa version can cause expected deviations. Your job is to validate that all changes are explainable and can be traced back to a specific migration or product change. Any unexplained changes are potential regressions that must be investigated. Phase 3: Full Environment Testing (UAT / Staging) Only after you are confident that most issues have been resolved should you move to a production-like environment with real, full-volume data. Full Regression & SIT: Execute your full test plan in this environment. This includes validating integration with external schedulers, security configurations, and any other real-world integrations. This is your best opportunity to catch elusive, data-specific edge cases. Performance Validation: Run your batch processes against full production data volumes. Compare the runtimes against your pre-upgrade performance benchmarks to ensure there are no significant performance regressions. User Acceptance Testing (UAT): This is a vital part of the release cycle. Block out sufficient time for business users to validate the solution and sign off on the upgrade. Factor in time to investigate and resolve any issues found during UAT and re-test. By following this phased approach, you systematically build confidence in your upgrade, ensuring that by the time you reach the most expensive testing phase, you have already eliminated the vast majority of issues in a more efficient manner.How to Perform an Incremental Upgrade
You have completed your planning and preparation, and you are now ready to begin the hands-on execution of the upgrade. This guide provides the step-by-step technical process for performing a single "hop" of an incremental upgrade (e.g., migrating from v2.5 to v2.6). The fundamental principle of an incremental upgrade is to migrate your project one major version at a time, ensuring the codebase is stable and validated at each stage before proceeding to the next. The Key Tool: The Repository Tool The Quantexa Repository Tool will be the primary engine for your upgrade. It uses a file generator called PLOPjs and code-modification tools like Scalafix to automate a significant portion of the migration effort. While powerful, this tool does not cover every scenario, and manual changes may therefore be required. The Workflow for a Single Upgrade Hop For each hop in your upgrade roadmap (e.g., from v2.5 to v2.6), you will follow this four-phase process. Phase 1: Automated Migrations The first step is always to let the automated tooling do the heavy lifting. This is a highly scripted process. For detailed instructions on the commands, refer to the documentation on Running the repository tool. Configure the Tool: Locate the migration-config.json for the version hop you are performing. Update the projectPath to point to your repository. Run Scalafix Migrations: Execute the Scalafix migrations first. Run Plop Migrations: Execute the relevant Plop migrations. It is best practice to run these one by one to create a granular commit history. Pro-Tip: If your project uses split repositories (e.g., separate ETL and Apps repos), only run the migrations relevant to the repository you are currently working on. Phase 2: Manual Migrations With the automated changes applied, you will now execute the manual tasks from the backlog you created in the preparation phase. Your JIRA board is your guide for this phase. Execute Manual Migration Tickets: Work through the JIRA tickets you created for the mandatory manual migrations. Each ticket should contain the context and a link to the specific documentation needed for that single task. Address Customization Tickets: Work through the tickets related to your project's customizations. These tasks involve reviewing how the upgrade has impacted your custom code and applying the necessary fixes to make it compatible. Execute Optional Migration Tickets: If you decided to include any optional migrations in your scope, execute those tickets now. Pro-Tip: Make small, specific commits for each distinct manual change (e.g., "Fix custom scoring function for v2.6 API change"). This creates a clean, traceable history. Refer to project-example to see how the same migrations were applied in Quantexa's reference project. Phase 3: Compile and Validate With the automated and manual changes applied, this phase is focused on compiling the code and validating its integrity by running the automated test suite. Compile the Code: The first action is to run a full build of the repository. If any compilation errors arise from the applied migrations, resolve them. These are typically caused by API changes or updated method signatures that impact custom code. Validate with Unit Tests: Once the repository compiles successfully, run your full suite of automated unit tests. Address any tests that are failing as a result of the upgrade changes. A successful, clean build with all unit tests passing marks the end of the development work for this hop. Phase 4: Intermediate Validation (Optional but Recommended) Before moving to the next hop, it is highly recommended to perform some level of intermediate validation to catch issues early. Run your automated integration tests. Perform a small, local ETL run to ensure the core process works. If practical, deploy the applications locally to check for runtime errors. Repeat and Finalize Once you have completed this four-phase process for one hop, you repeat the entire workflow for the next hop in your upgrade roadmap (e.g., v2.6 -> v2.7). After the final hop is complete and you have a stable, building repository on your target version, the hop-by-hop development phase is over. You are now ready to proceed with the full Development Testing as outlined in your test plan.Turn Your Upgrade Plan into Action: Creating JIRA Tickets
This is the final step of the preparation phase. You have a comprehensive Final Upgrade Plan that details every task required for the upgrade. Now, it's time to translate that plan into a structured, actionable backlog of JIRA tickets for the development team. A well-defined backlog is the bridge between planning and execution. It provides clarity for developers on what needs to be done, allows for accurate progress tracking, and forms the basis of your sprint planning. The Process: From Plan to Backlog The core input for this process is the "In Scope Tasks" table from your Final Upgrade Plan. Each row in that table should become one or more tickets in your JIRA backlog. Head Start: To accelerate this process, a set of template JIRA tickets for specific platform version upgrades can often be provided. Ask your Quantexa contact if a template is available for your upgrade path. You can then import and adjust these tickets to fit your project's specific scope. Action: Create Epics for Major Stages Start by creating a master Epic for the entire upgrade (e.g., "Platform Upgrade to v2.8"). Then, if you are performing a multi-hop upgrade, create a sub-Epic for each "hop" (e.g., "Upgrade 2.5 -> 2.6," "Upgrade 2.6 -> 2.7"). This provides a clear hierarchical structure. Action: Create a Ticket for Each Task Go through your "In Scope Tasks" table and create a JIRA ticket (e.g., a Story or a Task) for each line item. A good upgrade ticket is specific, actionable, and contains all the necessary context. What a Good Upgrade Ticket Looks Like Here are examples of how to structure tickets for different types of upgrade tasks. Example 1: Ticket for an Automated Migration Step Title: Run Repository Tool for v2.7 Migration Description: As a developer, I need to run the Repository Tool to apply the automated migrations for the v2.6 -> v2.7 upgrade. Acceptance Criteria: Repository Tool is executed successfully against the feature/platform-upgrade-v2.8 branch. All automated migrations from the v2.7 configuration are applied. The resulting code compiles successfully. Unit tests pass. Any failures or manual interventions required are documented in the Issue Tracker. Example 2: Ticket for a Manual Migration Step Title: [Manual] Upgrade Document Service Response Handling Description: As per the v2.5 migration guide, the response format for the Document Service has changed. We need to manually update our custom UI viewers to handle the new format, which no longer automatically converts Long values to datestrings. Reference: v2.5 Migration Guide#DocService Acceptance Criteria: All custom document viewers are updated to correctly parse and display dates from the new Document Service response. The UI correctly displays document information without errors. Example 3: Ticket for a Tech Debt Task Title: [Tech Debt] Decommission 'Legacy Data Feed' Description: As part of the upgrade, we will remove the unused 'Legacy Data Feed' configuration and all associated code from the ETL process. Reference: Project Backlog Item #1234 Acceptance Criteria: All configuration files related to the legacy data feed are deleted. All code that references the legacy data feed is removed. The main ETL process runs successfully without the legacy code. Planning for Parallel Work While many upgrade tasks are sequential, look for opportunities to parallelize work where possible. This is highly dependent on your project's specific architecture. For example, once the core ETL upgrade is complete and tested, the work to upgrade a separate "Scoring" repository and a separate "Apps" repository can often be done in parallel by different developers. With your backlog created and prioritized, the preparation phase is complete. Your team now has a clear set of tasks to begin the hands-on execution of the upgrade.Implementing Upgrade Tracking: What It Is and Why It Matters
Before you write a single line of code or run the Repository Tool, the first step of the preparation phase is to establish your system of record. Systematic tracking is essential for a successful upgrade, providing a clear, real-time view of progress, issues, effort, and project-specific complexities. This guide provides templates and best practices for setting up the core trackers that will guide you through the execution phase. A well-maintained set of trackers provides three key benefits: Real-time Visibility: Understand exactly where the project stands against the plan, allowing you to identify delays and manage stakeholder expectations. Knowledge Retention: Creates an invaluable audit trail of decisions made, problems solved, and customizations addressed, which is critical for future maintenance and subsequent upgrades. Improved Future Estimates: Capturing the actual effort spent on tasks provides a data-driven basis for more accurate future planning. The Customization & Risk Tracker This is the most critical tracker you will maintain. It documents your project's unique fingerprint, capturing not just code customizations but also environmental or programmatic risks that can impact the upgrade. It should be a living document, reviewed and updated throughout the project. Project Unique Attributes / Areas of Risk Use this table to capture peculiarities of your project that aren't code customizations but still pose a risk or add complexity. Area Description Estimated Maintenance Effort (S/M/L/XL) Estimated Remediation Effort (S/M/L/XL) Risk (Low/Medium/ High/Critical) Comments/Actions Last Reviewed Date CI/CD Uses a custom Jenkins pipeline, not the standard Helm charts. M L Medium The custom deployment scripts may need significant updates for the new version. 2026-03-26 Programme Shares a production data source with Use Case B. S S High Any changes to the shared source must be coordinated and tested with the Use Case B team. 2026-03-26 External Apps The external 'Fraud Dashboard' uses our Search APIs directly. L L Medium API response changes in the new version could break the dashboard. Needs specific integration testing. 2026-03-26 Customizations Use this table to capture any way your solution deviates from standard Quantexa best practice, as per the Customizations documentation. This includes everything from overridden functions to workarounds and significant technical debt. Area (ETL/Apps/etc.) Component Description Relevant Links (JIRA/Confluence) Est. Maintenance Effort (S/M/L/XL) Est. Remediation Effort (S/M/L/XL) Risk (Low/Med/High/Critical) Comments/Actions Last Reviewed Date ETL Post-Processing A custom Spark script runs after the main resolver to enrich entities from an external file. [PROJ-1234] M L Medium This script uses an internal API that may change. It needs to be reviewed against the new version. 2026-03-26 Apps Document Service Custom bean override to change document sorting logic. [PROJ-2468] L XL High This is a high-risk customization. The plan is to remove it and adopt the new out-of-the-box sorting feature. The Issue Tracker This is your central log for all problems, questions, and unexpected behaviors encountered during the upgrade. It prevents issues from being forgotten and helps identify recurring patterns. For detailed guidance, see Issue Tracking Best Practices. Ensure that any potential product bugs identified are fed back to Quantexa Support by raising a new post in Quantexa Platform Support on the Community. The Effort Tracker Tracking the actual effort spent is crucial for refining your project plan and improving future estimates. At the end of each major stage or sprint, update a simple effort tracking table. This provides a clear comparison of planned vs. actual effort. Area / Major Task Development Days Effort Testing & Bug-fixing Days Effort Total Days Elapsed for Acceptance Comments Repository Tool & Automated Migrations 2 3 5 Repository tool failed on two modules, requiring manual intervention. Manual Migration: Document Service 4 2 6 More complex than estimated due to unforeseen impacts on custom User Interface (UI) viewers. Manual Migration: ETL scripts 2 1 3 As expected. By establishing this system of tracking from day one, you create the visibility and data-driven foundation needed to successfully navigate the execution of your upgrade.Preparing For Success
You have successfully completed the planning phase and produced a comprehensive Upgrade Plan. You know what you need to do, how you're going to do it, and how long it will take. The Preparation Stage is the critical bridge between your plan and the hands-on execution of the upgrade. This is where you set up your project for success by establishing the right technical foundations, development processes, and support channels before the first line of code is migrated. A well-executed preparation phase minimizes friction, prevents common pitfalls, and ensures your development team can work efficiently and effectively once the upgrade work begins. Who is this guide for? This guide is primarily for Upgrade Leads and Developers who will be performing the hands-on work. Project Managers will also find the section on turning the plan into actionable tickets essential for tracking progress. What will you accomplish in this stage? By the end of this stage, you will have: Established a robust tracking system for all changes, decisions, and customizations addressed during the upgrade. Assembled all the necessary software, tools, and artifacts required for the upgrade. Established a clear development and environment strategy that allows upgrade work to proceed without halting business-as-usual development. Understood the support paths and processes available to you. Translated your high-level upgrade plan into a backlog of tangible, ready-to-work development tasks. The Preparation Process The following pages provide a step-by-step guide on how to best prepare for the execution of your Quantexa Platform upgrade. Page Description Implementing Upgrade Tracking: What It Is and Why It Matters Learn how to establish a robust system for tracking the upgrade process. This involves logging all issues encountered, the effort spent against tasks, and the details of customizations addressed or introduced. Maintaining these various trackers provides an essential audit trail and helps refine future upgrade estimates. Get Your Dependencies: What They Are and How to Obtain Them The essential next step. This guide covers how to locate and download all the required software versions, Quantexa release artifacts, and tools (like the Repository Tool) that you will need. Upgrading Without Stopping: Development Strategies and Environment Planning Learn how to set up your Git branching strategy (e.g., a long-lived upgrade branch) and plan your environment usage to isolate upgrade development from ongoing business as usual (BAU) work, ensuring both can proceed in parallel. Understanding Support During Upgrades: Where to Turn When Issues Arise Before you encounter a problem, it's vital to know where to go for help. This article outlines the different support channels available, from Documentation and Community to raising a formal Quantexa support ticket. Turn Your Upgrade Plan into Action: Creating JIRA Tickets The final preparation step. This guide shows you how to take the detailed "In Scope Tasks" list from your Upgrade Plan and convert it into a well-defined backlog of JIRA tickets, ready for your team to start working on.Produce Final Upgrade Plan
This is the final step in the planning phase of your Quantexa upgrade. You have now defined your destination, chosen your approach, detailed your scope, estimated the effort, profiled your team, and created a testing strategy. The purpose of this final step is to consolidate all these outputs into a single, formal Upgrade Plan document. This document will be your master guide for the execution phase and the primary communication tool for all project stakeholders. The Anatomy of the Upgrade Plan Document Your final Upgrade Plan document should be structured, clear, and contain all the key decisions and data you have gathered so far. Use the following structure as a template, pulling in the outputs from each of the previous articles in this guide. 1. Executive Summary 1.1. Project Goal: A high-level statement defining the purpose of the upgrade. What is the current version, what is the final target version, and what are the key business or technical drivers for this project? 1.2. Key Outcomes: Briefly list the major deliverables (e.g., "Upgraded Platform to v2.8," "Migration of ETL framework," "Decommissioning of legacy components"). 1.3. High-Level Estimate & Timeline: State the total estimated effort in days and the target completion quarter. 2. Upgrade Strategy & Roadmap This section details the "what" and "how" of the upgrade. 2.1. Target Version: The clearly identified major and minor version for your Quantexa Platform upgrade. This is the output from Identify Your Destination. 2.2. Upgrade Approach: State your chosen approach: Incremental Upgrade or Reset & Rebuild. If incremental, specify the release strategy: Single Go-Live or Staged Go-Live. This is the output from Define Your Upgrade Approach. 2.3. Upgrade Roadmap: Insert the detailed, staged roadmap table you created. This should show the sequence of all major projects (platform upgrades, infrastructure updates, framework migrations) required to reach the target version. This is the primary output from Identify Your Destination. 3. Detailed Project Scope This is the most detailed section of the plan, defining the precise boundaries of the work. It is composed of the tables you built in the Define Upgrade Scope article. 3.1. High-Level Impact Analysis: Insert the "Impacted Components" table (your "heat map"). 3.2. Out of Scope: Insert the table explicitly listing all items that are out of scope. 3.3. In Scope Tasks: Insert the definitive master list table of all migrations, one-off tasks, and tech debt items that are in scope for the project. 4. Effort Estimate & Resource Profile This section outlines the cost and the team required to deliver the plan. 4.1. Effort Estimate: Insert the final estimation table, including the sub-total, contingency, and grand total effort in person-days. This is the output from Estimate The Upgrade. 4.2. Resource Profile: Describe the planned team structure. State that the plan requires an Upgrade Lead and detail the planned team size based on your chosen approach. Note how the plan will leverage a Quantexa Architect/TDO and, if applicable, a Solution Expert. This is the output from Resource The Upgrade. 5. Testing Strategy This section summarizes the plan to ensure a high-quality, stable release, based on the outputs from the Define Testing Requirements step. 5.1. Guiding Principle & Focus Areas: Testing will be risk-based and targeted at the areas of greatest change as defined in the scope (Section 3). The primary focus will be on the components identified as "High" or "Medium" impact, such as ETL and the Mid-Tier. 5.2. Core Testing Activities: The following activities will be performed to validate the success of the upgrade: Testing Pillar Key Activities & Approach Regression Testing Validate batch outputs (ETL, Resolution, Scoring) against a pre-upgrade baseline using the Statistical Profile Testing Framework (SPTF). Manually execute high-value user journey test scripts for the User Interface (UI). Run automated test suites against key API endpoints. Systems Integration Testing (SIT) Perform end-to-end batch runs triggered by the production scheduling system. Verify successful deployment via the CI/CD pipeline, including database migrations. Conduct spot-checks on security and authentication. Non-Functional Testing (NFT) Capture pre-upgrade performance baselines for key batch jobs and API response times. Post-upgrade, execute the same tests to verify that performance has not significantly degraded and remains within acceptable SLOs. 5.3. Multi-Use Case Considerations (if applicable): This plan includes specific tests to validate the interaction between the upgraded Use Case A and the non-upgraded Use Case B, focusing on the shared Centralized Data Source to ensure continued compatibility. Moving to Preparation With this comprehensive plan assembled and approved by your stakeholders, the planning phase is now officially complete. This document is your charter to move into the Preparation Phase. This next phase involves setting up the necessary project structures, environments, and tooling required to begin the hands-on work. Your Upgrade Plan will guide all preparation activities, ensuring the team is perfectly aligned before the upgrade execution begins.Planning for Success
Planning for success with a Quantexa Platform upgrade is no different from planning for success in any other project. A well-defined approach, clear scope, accurate estimates, and appropriate resourcing are the essential foundations for creating an upgrade plan that is set up to succeed. This guide provides a comprehensive, step-by-step framework to help you navigate the process from start to finish. Who is this guide for? This guide is primarily intended for Project Managers, Technical Leads (TLs), and Delivery Owners who are responsible for planning and executing a Quantexa Platform upgrade. Business stakeholders and solution designers will also find the sections on scoping and testing requirements valuable. What will you learn? By following this guide, you will have the tools and knowledge to: Clearly define the goals and scope of your upgrade. Choose the right upgrade strategy for your specific circumstances. Accurately estimate the effort and resources required. Assemble a comprehensive and actionable final upgrade plan. Before you begin We assume you have a foundational understanding of your organization's current Quantexa implementation and general project management principles. Familiarity with your platform's architecture and existing use cases will be highly beneficial. The following pages provide a step-by-step guide on how to best plan an upgrade of your Quantexa Platform instance. The Upgrade Planning Process The following pages provide a step-by-step guide on how to best plan an upgrade of your Quantexa Platform instance. We have broken the process down into key stages to help you navigate the journey. Stage 1: Setting the Direction This initial stage is about defining the high-level goals and approach for your upgrade. Page Description Identify Your Destination Understand the target version of the platform and the key benefits it brings. Define Your Upgrade Approach Choose the right strategy, whether it's a "like-for-like" or a transformational upgrade. Planning A Multi-Use Case Platform Upgrade Learn the specific considerations for planning an upgrade on a platform that serves multiple business areas. Stage 2: Defining the Work This stage focuses on the detailed work of understanding the scope and effort involved. Page Description Define Upgrade Scope Detail the specific components, configurations, and customisations that are in scope for the upgrade. Estimate The Upgrade Follow a structured process to create a realistic and data-driven estimate for the project. Resource The Upgrade Identify the roles, responsibilities, and skills needed to successfully deliver the upgrade. Define Testing Requirements Create a robust testing strategy to ensure a high-quality outcome and build confidence with stakeholders. Stage 3: Creating the Plan This final stage brings everything together into a formal plan. Page Description Produce Final Upgrade Plan Consolidate all the outputs from the previous steps into a single, actionable delivery plan.