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.
Project Documentation to support you in upgrading Quantexa
One of Quantexa's priorities is to unlock the potential of your data while enabling customers to form their own self sufficient decision intelligence capability. Our Documentation team has outlined the requirements for upgrades, allowing you to prioritise needs against business benefit. This allows customers to assess through the following lenses: Which functionality update would help bring value to your organisation? Can additional functionality unlock other opportunities for Decision Intelligence in your organisation Are there any further technical or architectural requirements to consider when planning functional upgrades? How will these upgrades help with your end-user experience, or; Further the technical improvements of the platform? Where can you find this information? 📚️ As the Quantexa Releases are announced, the Documentation site explains the functional and non-functional updates, how they work, and how to implement the upgrades. As a Quantexa customer or partner, you will be able to access information around best practices to follow when upgrading your version of the Quantexa Platform on our Documentation site. In this section you will find guidance around Performing upgrades, Maintaining upgradable Quantexa implementations and Ongoing development during upgrades. Additionally, you can stay updated with the latest releases by subscribing to Release Announcements or reach out to your TAP (formerly CSMs & SSMs) to set up a meeting with the required team members. Quantexa can demonstrate the functional updates and discuss the benefits and effort requirements in order to help you plan out your platform roadmap, for your current needs or those you may have in the future. We are here to support you in any way you need. Additional resources For more information check out our blog: So you want to perform an upgrade? 💬 Do you have any questions or thoughts around scaling/upgrades that you would like to discuss with other Quantexa customers and experts? Ask your question in Quantexa Platform Support.
Read now: What it's Like to Perform an Upgrade
Read all about our experience and key takeaways when upgrading a repository from version 2.1 to 2.3. The upgrade was performed and released in early 2023 shortly after version 2.3 became available. The main motivation behind this particular upgrade was to upgrade the batch tier software including versions of EMR & Spark which Quantexa 2.3 supported. The flexibility of the new Data Viewer and other newly released features were also important value-adds. What's it Like to Perform an Upgrade? - Quantexa Community This blog describes the experience and key takeaways when upgrading a repository from version 2.1 to 2.3. The upgrade was performed and released in early 2023 shortly after version 2.3 became available. Why upgrade Quantexa versions? As with any software, the advantages of upgrading to newer versions include: Access to new…
Why Does Entity Quality Matter? & Best of the Community from March
March Top Picks Why Entity Quality Matters 🔐login required Enter our latest competition: The Knowledge Exchange 📝 New Education Programs: Scala & Spark Bootcamp and Quantexa Data Engineer Velocity Program Quantexa & Xander Talent - New Education Partnership 🤝 Elevating Data Management: Unveiling the Pillars of a Trusted Data Foundation with Quantexa Latest from the Community Library 📖 A day in the life of a... Senior Learning Designer A day in the life of... an Academy Trainee How To Test Your Upgrades 🔐login required Updates to Quantexa Supported Versions 🔐login required Upcoming events 🗓️ 3rd May Community Connect 👋 Join for a demo of top Community features. Best of Q&A ✅ Unable to load Batch Scores to Elastic 🔐login required How to fix image style for investigation icon in the Qx UI? 🔐login required Error creating bean with name 'springSecurityFilterChain' 🔐login required New & Popular Ideas💡 Usability increase using 2 screens for investigations 🔐login required Changing the default settings for Graphic Filters in Data Viewer 🔐login required Make updates to metadata.parquet optional 🔐login required In case you missed it 📣 Welcome to Quantexa 2.6 | 2.6.0 Release Announcement 🏆 Badge of the Month: The Name Dropper Badge Community quick links 🚀 Submit and vote for Ideas in our Ideas Portal 🗣️ Join one of our Specialist User Groups: FinCrime, Insurance, Data Management & KYC 📚️ Browse blogs, articles and guides in our Community LibraryHow 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.Get Your Dependencies: What They Are and How to Obtain Them
With your tracking in place, the next step is to gather all the software, tools, code, and access rights you will need to perform the upgrade. Having all dependencies ready and provisioned before starting development is crucial to avoid delays and interruptions. This guide provides a checklist of the key dependencies you will need to acquire. Checklist Item 1: The Quantexa Core Dependency Bundles These bundles contain the core Quantexa product artifacts (libraries and other dependencies) required to build the project against the new versions. Action: Obtain the dependency bundles for every version "hop" in your upgrade path. For example, an upgrade from v2.5 to v2.8 requires the bundles for v2.6, v2.7, and v2.8. How to Obtain: These bundles are not publicly downloadable. You must request them from your Quantexa contact. They will provide you with the necessary files. What to Do: Once received, upload the artifacts to your organization's repository management tool (e.g., Nexus, Artifactory). Ensure that both Maven and NPM artifacts are provisioned. The official documentation provides an example of how to upload to Nexus. Missing Dependencies: If you encounter issues with missing third-party dependencies during your build, it may be because your environment has no access to public repositories like Maven Central. The bundles are designed to be self-contained, so if you believe something is missing from the bundle itself, please raise a post in Quantexa Platform Support on the Community. Checklist Item 2: Component-Specific Bundles (If Applicable) If your solution uses certain Quantexa components like Data Packs, Decision Systems, or QPython, these have their own dependency bundles. Action: Check if your "In Scope Tasks" list from your upgrade plan includes upgrades to these components. If so, you must also request the specific dependency bundles for the target versions of these components from your Quantexa contact. Checklist Item 3: The Repository Tool The Repository Tool is the primary mechanism for automating the code migration between versions in an incremental upgrade. Action: Obtain the Repository Tool executable and the specific migration configuration files for every version "hop". How to Obtain: The tool and its configuration can be provided by your Quantexa contact. Further guidance can be found in the documentation: Download Repo-Tool. Checklist Item 4: Project Example project-example is Quantexa's reference implementation and an invaluable resource. It contains best-practice examples and shows how to correctly apply the migrations for each version. Having a local copy is highly recommended. Action: Get access to the project-example Git repository and, if necessary, transfer a copy to your development environment. How to Obtain: Follow the guidance here to get access: Accessing project-example. Checklist Item 5: Database Migration Scripts (If Applicable) Platform upgrades may introduce database schema changes. For some database technologies (like Oracle), these migrations must be run manually. Action: Discuss with your Quantexa Architect whether manual database migrations are required for your specific technology stack and target version. If they are, you must request the DDL (Data Definition Language) scripts from your Quantexa contact. Checklist Item 6: People and Places (Environments & Access) Software and code are only part of the equation. Ensure the team is fully enabled and the necessary environments are available. Action: Confirm the following before development begins: Team Onboarding: Ensure all developers on the upgrade team have been fully onboarded. System Access: Verify that every team member has the required access to all necessary systems (e.g., Git repository, artifact repository, JIRA, development/test environments). Environment Availability: Confirm that the required development and testing environments have been provisioned and are available for the project. These non-production environments are critical for isolating the upgrade work. With all these dependencies gathered and correctly placed, your team is now equipped with everything it needs to begin the hands-on development work.Define Your Upgrade Approach
Having created your Upgrade Roadmap, the next critical decision is to define how you will execute the work. There are two fundamentally different strategies for upgrading your Quantexa platform: the Incremental Upgrade and the Reset Upgrade. This page will guide you in selecting the right approach for your specific context, considering factors like your roadmap's complexity, your solution's health, and your team's capacity. At a Glance: Comparing the Approaches Approach Key Characteristic Best For... Primary Benefit Key Consideration Incremental Upgrading through each major version sequentially ("hopping"). Solutions that are well-aligned with Quantexa best practices and are only a few versions behind. Efficiency. Maximises automation using the Repository Tool. The Repository Tool is less effective on solutions with high technical debt. Reset Creating a new, clean repository on the target version and migrating code selectively. Solutions that are many versions behind or contain significant technical debt. Clean Slate. An opportunity to remove technical debt and realign to best practices. Higher initial manual effort to set up and selectively migrate logic. In-Depth: The Incremental Upgrade This is the most common and efficient approach. It involves upgrading your existing repository through each major version between your current state and your target destination. For example, moving from v2.5 to v2.8 would involve separate, sequential upgrades to v2.6, v2.7, and finally v2.8. This approach makes maximum use of Quantexa's Repository Tool, which is designed to automate much of the migration effort between sequential versions. This is the default and recommended option if you are only upgrading a single major version (e.g., from 2.7 to 2.8). When performing an incremental upgrade across multiple versions, you have two release strategy options: Option 1: Single Go-Live Perform each version "hop" in quick succession within your development environment, but combine them into a single release package. This package goes through one cycle of SIT, UAT, and Production deployment. Benefits: Reduced Testing Overhead: One round of formal SIT/UAT saves significant time and effort. Faster Time-to-Target: Achieves the final goal of deploying the target version in the shortest overall project duration. Developer Efficiency: Developers build deep expertise by performing the "hops" back-to-back, increasing speed. Option 2: Staged Go-Live (Release per Hop) Treat each version "hop" as a mini-project. You develop, test (SIT/UAT), and release each incremental version to Production before starting the next hop. Benefits: Lower Risk per Release: Each deployment is smaller and more contained, simplifying testing and root cause analysis if issues arise. Incremental Value: End-users can benefit from new features and improvements more regularly. Increased Flexibility: Allows your team to address other business priorities between upgrade stages. In-Depth: The Reset Upgrade This approach involves creating a brand-new, empty repository on the target platform version. Your team then selectively migrates or completely rebuilds the required logic (data interfaces, Entity Resolution, Scoring, etc.) from the old repository into the new one. This is a strategic choice to "pay down" technical debt. Benefits: Your implementation is multiple major versions behind the latest Quantexa Platform release. The current solution contains a high degree of technical debt, making an incremental upgrade complex and risky. You need to make significant architectural changes or re-align to modern Quantexa best practices. While this approach requires more upfront manual effort, it ensures that your repository is clean, modern, and optimized for future scalability and smoother upgrades. How to Choose Your Approach Your choice will depend on the specifics of your Quantexa deployment and the goals of your upgrade. If your solution is well-aligned with best practices and your Upgrade Roadmap involves only one or two hops, the Incremental approach is almost always the best choice. If your solution suffers from significant technical debt or your Upgrade Roadmap spans many major versions, the Reset Upgrade approach offers a powerful opportunity to reset for the future, even if the initial effort is higher. Quantexa's Divergence Tool can help provide insights into how far away from best practice the deployment is in certain areas The output of this step is a clear, documented decision on the approach you will take. Action: State your chosen upgrade approach. Example: We will follow an Incremental Upgrade approach with a Single Go-Live release strategy.2.6 Quantexa Upgrade Guide
Quick Upgrade Overview This article provides a practical review of the Quantexa 2.6 upgrade, highlighting key areas to watch out for based on collective project experience. It should be used as a strategic companion to the official technical guides. Official Migration Guide: 2.5→ 2.6 Upgrade Migration Guide Release Information: Community Release Announcement | 2.6.0 Release Notes The 2.6 upgrade has several non-negotiable prerequisites. Before beginning, it is essential to confirm that your project has already completed the following: All Data Sources on Data Fusion: If you have any data sources on the legacy Lenses framework, they must be migrated first. The full process is detailed in Migrating to Data Fusion. Scoring on Assess Framework: For projects still on Scoring Framework 1.0 (SF1), migrating to Assess is mandatory. This is not a direct technical conversion; it requires upfront design work to identify the right course for your project. The outcome could be to adopt modern Detection Packs if there is a good fit with your existing scoring logic, or it could be to re-implement your logic as custom scores within the Assess framework. It is strongly recommended to discuss your approach with a Quantexa Architect to determine the best path forward. For guidance on the technical migration, see Migrating from Scoring Framework 1.0 to Assess. Fusion-Compatible Data Packs: Ensure all Data Packs used by your project are the modern, Fusion versions. Check the Data Pack Compatibility Matrix to confirm your versions are compatible with Quantexa 2.6. Community Upgrade Guidance Core Product Changes Delta Lake Configuration: A straightforward configuration change in the spark-submit command. The key consideration is ensuring the Delta Lake version in your dependency-versions.gradle file is compatible with your Spark version, which can be verified on the Delta Lake release page. Explorer-*.json Configs: Simple manual edits are required to align with updated JSON schemas in some Batch Resolver configuration files. Batch Resolver Changes: A straightforward manual config change in reference.conf. The resolver now generates more output files; while a compatibility script is provided, it may be cleaner in the long run to update any downstream test code to handle the new format directly. Graph Script and Assess Imports: This is handled automatically by the repository tool, which refactors the library imports. Assess Changes: This area typically requires significant attention. The Batch Resolver data models have changed, which has a direct impact on Assess. If your scoring logic uses Entity Attributes, expect to refactor custom steps, as some fields have been removed or had their data types changed. Other Migrations Java 17 Upgrade: This is a significant undertaking that extends beyond the codebase. It requires upgrading the JDK across all environments: local developer machines, Docker images, CI/CD runners, and the production Spark clusters. It is crucial to engage with platform and infrastructure teams early to plan this. Gradle 8 Upgrade: The migration to Gradle 8.4 can be complex. An efficient approach is to generate a clean project using the 2.6 Repository Tool and use its working Gradle setup (build.gradle, settings.gradle, etc.) as a reference for your own project. LiteGraph to ScoringGraph Migration: A key migration with both automated and manual steps. This is a worthwhile effort, as ScoringGraph unlocks significant new functionality, most notably support for Entity-to-Entity edges and compatibility with the new Attribute types from the updated resolver configs. The repository tool handles much of the refactoring, but manual intervention is still required. Following the official Migrating to Scoring Graph guide closely is recommended. Alert Scorecard Migration: It is critical not to overlook this one-off data migration script for historical alert data, which is necessary to ensure re-alerting performs correctly once upgraded. Refer to Migrating from Alerting 2.5.x to 2.6.x for detailed guidance. Task View table Migration: This migration updates the database schema for the Task Data visible in the UI, typically by adding two new columns. The process depends on your database technology. For RDBMS systems, this involves running DDL migration queries. Crucially, these DDL scripts are not included in the main dependency bundle; they are provided in a separate ZIP file that must be downloaded from the Quantexa artifact repository. Additional Information For more general best practices on topics such as setting up development strategy, testing your migrated code, and releasing your upgrade, please refer to the other articles within the Upgrade Platform Library on the Quantexa Community site.Estimate The Upgrade
With a clearly defined scope document in hand, you are now ready to build a reliable effort estimate. This process translates your detailed list of tasks into the person-days required to complete the project, forming the bedrock of your final upgrade plan. This guide provides a practical, bottom-up estimation process. It should be used alongside the official documentation's guide on Key factors impacting upgrade effort, which provides essential context on what makes an estimate go up or down. The estimation method you use will depend directly on the Upgrade Approach you selected earlier: Incremental or Reset. Estimating an Incremental Upgrade For an incremental upgrade, the most reliable estimate is built from the bottom up. You will estimate each individual line item from your "In Scope Tasks" table, which you created during the "Define Scope" phase. Action: Build your bottom-up estimate. For each task, estimate the development and unit testing effort. This detailed breakdown ensures you account for every specific migration and change required. To help with this process, detailed Work Breakdown Structure (WBS) templates for specific platform version upgrades can be requested from your Quantexa contact. Task / Migration Description Category Dev Effort (days) Unit Testing (days) Total (days) Upgrade Document Service response handling Manual Migration 3 1 4 Execute database schema update One-Off Task 0.5 0.5 1 Refactor deprecated custom-function-x Tech Debt 2 1 3 Run Repository Tool for v2.7 migration Automated Migration 1 2 3 ...add all other tasks... Sub-Total X Y Z Action: Validate your estimate with the top-down model. Now, use the best practice estimation approach from the Documentation Site as a sense-check. Start with the baseline (e.g., 8 days) and adjust it based on the key factors. Does your detailed, bottom-up total roughly align with the top-down adjusted baseline? If they are close, you can have high confidence in your number. If they are far apart, it's a crucial signal to review both your detailed estimates and your understanding of the influencing factors: Have you underestimated the complexity of a required migration? Have you overestimated the negative impact of your customizations? Action: Add contingency and formal testing. Finally, add a contingency buffer to your sub-total to account for unforeseen issues. Remember, this estimate is for the development and unit testing effort only. The effort for formal testing cycles (SIT, UAT, OAT) must be estimated and added separately. Estimating a Reset A "Reset" project is estimated in much the same way as a brand-new Quantexa implementation. The focus is on estimating the effort required to selectively re-implement the desired functionality in a new, clean repository. Action: Estimate the "re-implementation" effort for each functional block. For each major component of your current solution (e.g., Entity Resolution, Scoring), estimate the effort to build it in the new target version. When doing so, you must factor in the effort to align with modern best practices and to remove the technical debt you identified in your existing customizations. Functional Block Re-Implementation Effort (days) Notes Data Ingestion & Parsing 15 Includes refactoring 3 custom parsers. Entity Resolution 20 Involves re-implementing logic to align with new best practices. Scoring & Alerting 10 UI & Document Views 12 Includes rebuilding 2 custom document viewers. ...add other functional blocks... Sub-Total X As with the incremental approach, a healthy contingency should be added to this sub-total, and formal testing should be estimated as a separate line item. ⚠️Warning: Avoid the "Big Bang" Trap A reset upgrade provides a tempting opportunity to tackle other major platform migrations at the same time (e.g., historical Fusion or Assess migrations, Parsers v4). While this can be efficient, be extremely careful about letting the scope balloon. The effort to validate major functional changes, combined with the cost of a very long-running project, can quickly become unmanageable. It is often better to treat these as separate, subsequent projects.Define Testing Requirements
With your scope, estimate, and resource profile defined, the final step in planning is to create a robust testing strategy. The goal of upgrade testing is not to re-test your entire solution from scratch; it is a risk-based exercise designed to build confidence that the upgrade has not introduced any negative impacts and that the platform remains stable. This guide provides a framework specifically for upgrade testing. It should be read in conjunction with Quantexa's High-Level Testing Methodology for a broader understanding of testing best practices. The Guiding Principle: Test Your Scope Your testing effort should be directly proportional to the scope of change you have already defined. There is no need to review release notes or other documentation again; your "Define Upgrade Scope" document is the single source of truth for what needs to be validated. Action: Identify your areas of focus from your scope document. "Impacted Components" Table: This "heat map" tells you where to focus the most testing effort. A component marked with "High" impact requires a more thorough validation than one marked "Low". "In Scope Tasks" Table: Every line item in this table, especially manual migrations and tech debt removal, should have a corresponding test case to validate that the change was successful and didn't have unintended consequences. The Core Testing Pillars Your test plan should be built around three mandatory pillars. The articles below describe how to perform these tests in detail; this section describes what to focus on in an upgrade context. Pillar 1: Regression and Functional Testing Goal: To ensure existing functionality has not been broken by the upgrade. The focus is on validating the outputs and core functions of your solution. For detailed methodologies, refer to the main Deployment Regression Testing and Functional Testing articles. Upgrade Focus: Use the Statistical Profile Testing Framework (SPTF) to efficiently automate the validation of your batch process outputs (ETL, Entity Resolution, Scoring). Pillar 2: Systems Integration Testing (SIT) Goal: To ensure all components of your solution (platform, infrastructure, schedulers, authentication) integrate correctly in a production-like environment. Area Key Activities End-to-End Batch Validate that your external scheduling system can successfully trigger and complete full and incremental batch runs. Deployment & Stability Validate that your CI/CD process can deploy the application services successfully and that any automated database migrations run as expected. Let the services run to ensure stability. Security Spot-check that users can log in via your authentication provider, that API keys function, and that a sample of roles/policies are being correctly enforced. Pillar 3: Non-Functional Testing (NFT) Goal: To ensure the performance, stability, and security of your solution remain within acceptable service level objectives (SLOs). For detailed methodologies, refer to the main Non-Functional Testing Recommendations article. Upgrade Focus: The key is to establish a pre-upgrade baseline for batch runtimes and critical API response times. Your post-upgrade testing should then focus on verifying that there are no significant performance regressions against this baseline. Multi-Use Case Testing Considerations If you are upgrading a platform that hosts multiple use cases, your testing must account for the interaction between them, especially if you are upgrading one use case at a time. Testing Shared Dependencies: If an upgraded use case consumes data from a shared, non-upgraded component (like a centralized data source), you must test to ensure this interaction still works correctly. Testing Upgraded Shared Components: If you are upgrading a shared component itself, it is critical to perform regression testing for all consuming use cases, including those that are not being upgraded in this cycle, to ensure they are not negatively impacted. With a documented test plan covering the core pillars and any multi-use case considerations, you are ready for the final step: Produce Final Upgrade Plan.
