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 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.
FAQ: Academy Documentation Links
Hey all! Here are some useful links for the Academies: ETL Configuring .qmodel files Configuring .qentity files Entities, Start Paths, and traversals Defining Traversals Defining Compounds Defining Elements Quantexa Core Library Core Traversals Core Elements Core Templates Address Business Individual Core Compounds Address Business Individual + Individual Synonyms Core Parsers Address Business If Business parse Business If not Business parse Individual Date to Date parts Entity Resolution Resolver Config Resolution Templates Filtered Compounds Compound Exclusions Network Generation Expansion Steps Scoring (v2.1.8) Severity Tooling Assigning Severity to a Score Configuring Score Descriptions Score Descriptions Score Description Rendering Extracting Values from Configuration files Scorecard Configuration For Comprehensions (Scala Documentation) Project Example - Scoring Best Practices UI Search Configuration Expansion Templates Traversal DSL Functions home page Example Note: The Data Engineering is currently on v2.0.1 of the Quantexa Platform and the Scoring Engineer Academy is currently on v2.1.1, however the closest documentation versions we have are for v2.0.8 and v2.1.8 respectively. These versions should be sufficient for you to complete the Academy! Please comment below if you find any other useful links from the Quantexa Documentation Site so we can add them to the list!
Scoring Concepts Resources
This series of articles explores the foundational concepts behind building a performant and high-quality Batch Scoring solution in Quantexa. Each article breaks down a key component of the scoring process — from network generation and scoreable models to alerting and network pruning — offering practical guidance and design considerations. How will the articles help your team and deployment? Whether you're new to Batch Scoring or refining an existing implementation, this content provides a clear, structured approach to best-practice design. By understanding and applying these concepts, teams can ensure their scoring solutions are efficient, scalable, and investigator-friendly — ultimately driving better outcomes from their Quantexa deployments. Make sure you're signed in to the Community to access the articles. Articles in the series: Scoring Concepts: Run Date Scoring Concepts: In-Scope Customers Scoring Concepts: Scoring Levels and Scorecards Scoring Concepts: Scenarios & Risk Factors Scoring Concepts: Alerting and Re-alerting Scoring Concepts: Write-Once Steps Scoring DAG Design in Assess
Scoring Concepts: Scenarios & Risk Factors
This guide explains how to differentiate between Scenarios and Risk Factors. At Quantexa, we aim to give our clients meaningful Alerts. We focus on those that pose the highest risk to investigators. This article targets Business Analysts, Business End Users, and Subject Matter Experts (SMEs). It focuses on individuals engaged in risk assessment, decision-making, or developing Scores. When readers grasp these distinctions, they can design Scores and Scorecards better. This helps us show only the most relevant risk profiles to investigators. Read the full article for: Definition of Scenarios and Risk Factors Best Practices for Setting Scenarios vs Risk Factors How Scenarios and Risk Factors affect Alerting and Re-Alerting Using Detection Packs & Risk Factors - Quantexa Community 4. Scoring Concepts: Scenarios & Risk Factors - Quantexa Community This article explains how to differentiate between Scenarios and Risk Factors. At Quantexa, we aim to give our clients meaningful Alerts. We focus on those that pose the highest risk to investigators. This article targets Business Analysts, Business End Users, and Subject Matter Experts (SMEs). It focuses on individuals…Scoring Concepts: Network Generation & Design
Learn Effective Network Generation & Design Explore the essential concepts and tools behind network generation in Scoring Concepts: Network Generation & Design. Networks are central to Quantexa solutions, offering context to complex datasets through nodes and edges. Nodes can represent either: Documents, a hierarchical representation of raw data, or Entities, real-world concepts like individuals, businesses, or accounts created through Entity Resolution. This article covers: Network Design and Scoring: How to create networks that meet your project needs. Network Types: The differences between Natural Networks and Ego-centric Networks. Graph Script DSL Expansion Tips: Practical advice for generating high-quality ego-centric networks. For additional guidance, check out Graph Scripting Best Practices, or log in now to read the full article: & Design - Quantexa Community 1. Scoring Concepts: Network Generation & Design - Quantexa Community This article introduces some concepts, tools and tips on the topic of network generation. By the end, you should understand which tool you would use to generate networks for your project and how to ensure the network output will cover the scores you have in your project. Introduction Networks are at the core of any…
Scoring Concepts: Network Scoring
We can feed networks derived in Graph Scripting DSL into a Scoring pipeline to derive information and insight in the form of network-based scenarios. This article outlines: Concepts and approaches available for batch Network Scoring, including extracting information from graphs, testing, and debugging. Available tools and methods for performing network analysis with Assess. Read the article (login required): 2. Scoring Concepts: Network Scoring - Quantexa Community This article outlines the concepts and approaches available for batch Network Scoring, including extracting information from graphs, testing, and debugging. This article also highlights the available tools and methods for performing network analysis. The below steps are applicable for Assess only. Introduction We can feed…
Scorecard Tuning📋
Scoring is a key part of the Quantexa Platform, and to maximise effectiveness needs to be tuned in an ongoing iterative process. There are various elements in the scoring process that can be tuned, and this article serves as a guide as to methods that can be employed to do so. Read the full article (login required): 1. Scorecard Tuning - Quantexa Community Introduction Scoring is a key part of the Quantexa Platform, and to maximise effectiveness, needs to be tuned in an ongoing iterative process. There are various elements in the scoring process that can be tuned, and this article will serve as a guide as to methods that can be employed to do so. What can be Tuned? There are…
New guide 📖 Scoring Concepts: Write-Once Steps
Discover how to efficiently use Write-Once Steps in the Assess framework for data transformation. This detailed guide complements the Write-Once Steps documentation and helps you determine when to apply Write-Once Steps effectively in both Batch and Dynamic Scoring contexts. Key topics covered: The potential cost of using the wrong method When to use Write-Once Steps vs. Logical Sources Strategies for scoring networks in Batch (SparkScoringContext) and Dynamic (DynamicScoringContext) environments Gain a deeper understanding of how to avoid duplicating logic across contexts and streamline your data engineering workflows. Read the full article (login required) to explore practical scenarios and best practices for scoring networks with Write-Once Steps: 5. Scoring Concepts: Write-Once Steps - Quantexa Community This article serves as an extension of the Product documentation of Write-Once Steps and provides a guide on which situation should the Write-Once Steps be used. Introduction The Write-Once Step is a data transformation step in the Assess framework, which is executable in both Batch and Dynamic contexts, meaning you do not…
FinCrime Detection Pack 0.4 is now available
We are excited to announce version 0.4 of our FinCrime Detection Pack is now available in Early Access. This release introduces new features that will increase flexibility, improve score coverage and optimise score configuration to better capture desired behaviours, characteristics and events. This builds on the functionality released in version 0.3 of the FinCrime Detection Pack. Feature Highlights: You can now apply score logic on a targeted subset of transactions to help you uncover more specific underlying patterns that might otherwise be overlooked. You can now configure transaction score parameters based on the segment a score subject belongs to. This allows you to account for differences and ensure that you are capturing the behaviours and events you’re interested in. You are now enabled to select from a range of appropriate Event Windows to ensure that a score is targeting the desired behaviour or event. Target new risks with additional Score Types You can read more about the release in Detection Pack 0.4 Release (login required) For full details of the release, including compatible Quantexa Platform versions and minor enhancements, please see the Quantexa Documentation site. Release notes Migration guide
