BlueGecko Suite Release Notes

Object Governance, Named Ownership per Migration Object

Accountability for a migration object such as Customer or Supplier was previously agreed at project kick-off and recorded outside the platform. When a data issue surfaced later in the programme, establishing who held the decision required reconstructing that agreement from correspondence. A new Object Governance tab now holds this assignment inside the product.

• Role-aware assignment. Users are presented grouped by role and then by designation, Business Users as Data Steward or Data Owner, Consultants as Functional Consultant, Developers as Data Engineer, and are assigned to objects by drag and drop. The structure reflects how delivery teams are organised rather than presenting a flat user list.
• Controlled permissions. Only stakeholders, project managers and administrators may assign users to objects. Ownership cannot be reassigned by an individual team member.
• Persisted configuration. Assignments are stored against the organisation configuration and travel with the project, providing a single authoritative record of accountability.
• Audit readiness. Data ownership can be evidenced directly from the platform during client and regulatory review, without assembling supporting documentation.

Object Migration Load Order, Cutover Sequencing

Migration objects carry dependencies, Products must precede Bills of Material, Customers must precede Sales Orders. The intended sequence previously lived in a runbook document maintained outside the platform. An incorrect sequence costs a full reload cycle during a dress rehearsal and jeopardises the window during cutover. A second Data Governance tab now holds the agreed sequence centrally.

• Repeatable rehearsals. The same agreed sequence is applied to every rehearsal cycle, eliminating a recurring and avoidable source of rework.
• Risk moved forward. Sequencing is decided and reviewed weeks ahead of cutover rather than resolved under time pressure.
• Simplified handover. Team members joining the programme read the intended order directly from the product.

Business Rules, Formal Definition of Migration Scope

• Scope becomes an artefact. Rules are named, stored and available for client review, rather than existing as a shared recollection of an agreement.
• Business ownership of definition. Scope is expressed by the stakeholders who understand the data, removing a translation step into development.
• Volume established early. A preview displays the records a rule selects before it is committed, informing effort and runtime estimates during planning.

were agreed in workshops and subsequently interpreted independently by each person implementing against them. Business stakeholders can now define named business rules that express scope as saved conditions per object within the organisation configuration.

Governance Change Notifications

Governance decisions are effective only when the affected parties are aware of them. An ownership reassignment or a revised load order previously required a separate manual communication, and teams frequently continued working against a superseded position. Falcon Mapping now raises a notification automatically when governance configuration changes.

• Owner assignment change. Where object-level ownership is amended, all users with access to that object in Falcon Mapping are notified.
• Hierarchy or business rule change. Where the object hierarchy order is amended, or a business rule is created or updated, all users under the respective organisation configuration are notified.
• Persisted delivery. Notifications are stored rather than transient, allowing users returning after a period of absence to review changes made in their absence.

AI-Assisted Dependency Discovery

Dependency relationships between objects are now surfaced with AI assistance, so that the proposed load order is informed by relationships identified in the source data rather than assembled solely from documentation and prior experience. Dependency mapping is among the most experience-dependent activities in a migration; reducing that concentration shortens ramp-up on new engagements and lowers the delivery risk carried by individual consultants.

Natural-Language Metadata Intelligence, 17 Capabilities

Routine enquiries during a migration, which tables constitute a business object, which fields are mandatory, what is affected by a proposed change, previously required navigating mapping documents, data dictionaries and ER diagrams, or consulting a specialist. This work is repetitive and concentrated among a small number of individuals. Seventeen distinct capabilities are now answered directly by the assistant in plain English.

• Self-service validation. Capabilities 12 and 13 enable testers to confirm mappings independently rather than queuing for consultant availability.
• Change control. Capability 15 converts impact analysis from an investigation into a query, providing the most direct defence against defects introduced by late scope changes.
• Business participation. Capability 14 allows data owners to locate fields in business language, which is a precondition for meaningful stakeholder involvement.
• Reduced onboarding time. Capabilities 6, 7 and 16 allow new team members to explore the data model conversationally, compressing ramp-up.
• Cost decoupled from usage. Additional projects and users no longer incur incremental AI cost, removing usage caps and internal approval steps.

Voice Input and Reworked Assistant Interface

Users may now submit questions by voice in addition to typing. The assistant interface has been rebuilt around the new service.

• Conversation continuity. Conversations can be initiated, resumed and revisited without loss of prior work.
• Mapping and lineage together. Dedicated views allow users to move between proposed mappings and the lineage supporting them.
• Consistent system feedback. Loading states, error handling and readable formatting replace opaque waits and unformatted output.
• Design system alignment. The assistant now follows BlueGecko presentation standards rather than operating as a separate interface.
• Hands-free access. Voice input supports use during client workshops, design sessions and cutover calls, and lowers the barrier for non-technical business users.

Third-Party Application Integration

Connect third-party tools and platforms to automate workflows and enrich your mappings across all your connected apps. Integrations with Azure DevOps and Jira are available in this release, supporting read and write operations directly from the BlueGecko interface.

• Read operations. Work items, tickets and project data are retrieved into BlueGecko, so that mappings carry the delivery context surrounding them.
• Write operations. Findings and change requests raised during mapping are recorded as tracked items in the connected system without manual re-entry.
• Single working context. Migration work and project tracking remain aligned rather than diverging across two systems.
• Extensible connector set. Further connectors are in development, allowing BlueGecko to operate within an established toolchain rather than displacing it.

The principal advance in Owl Sight is that data quality is no longer measured by independently configured checks. It is measured against governance standards the organisation has formally approved, held within the product.

Data Governance Relocated to Owl Sight

The Data Governance module has moved from Falcon Mapping into Owl Sight. Functionality, navigation and permissions are unchanged, so no retraining is required. Governance belongs alongside data quality and issue prediction rather than alongside mapping. Consolidating it within Owl Sight establishes a single destination for the oversight questions, ownership, quality and predicted risk, and provides the foundation for the cross-product governance reporting signposted in v1.1.0.

Governance Rules Held Within the Product

Governance rules, data standards and ownership were previously distributed across spreadsheets and, in practice, retained by a small number of experienced individuals. No controlled location existed in which to state the accepted standard for a given object. These are now defined and managed within Owl Sight as a single source of truth.

• Institutional knowledge retained. Standards persist through team changes because they are held in the platform rather than by individuals.
• Authoritative definition. Questions regarding the content of a rule are resolved by reference rather than by discussion.
• Reviewable governance. Clients and auditors may inspect the standards themselves, not only the results derived from them.

Governance-Driven Data Quality Analysis

Data quality analysis under the BAU template now executes against the rules defined in the Data Governance module rather than against separately configured checks. Results measured against an approved, documented standard are consistent, repeatable and defensible to auditors and business stakeholders, a materially different position from analysis produced by ad-hoc configuration, where the selection of checks itself becomes a subject of discussion.

SAP S/4HANA Connectivity for Data Quality

Data quality can now be assessed directly against SAP S/4HANA source data under the BAU template, without manual extracts. Removing the extract step is significant in practice: extracts introduce delay and effort, with the consequence that quality is assessed late and infrequently. Direct connectivity allows issues to be identified earlier in both the migration and the ongoing BAU cycle, and extends BlueGecko's applicability beyond the migration event into recurring data operations.

Persistent Chat History and Conversation Management

Conversations in the BAU and General templates are now retained across sessions, supported by an improved dashboard for returning to earlier investigations.

• Context preserved. Analysts no longer repeat an analysis following an interruption or a handover.
• Audit trail of reasoning. Prior findings record how a data quality conclusion was reached, not solely the conclusion itself.
• Shareable findings. An investigation can be passed to a colleague or client as a record rather than re-narrated.
• Efficient recurring checks. BAU cycles build on earlier work rather than duplicating it across the team.

Issue Predict, Knowledge Base Enriched Across SAP Objects

The knowledge base underpinning Issue Prediction has been completed across all SAP migration objects and enriched with project README rules, dependent objects and table relationships. The Issue Predict service and interface were updated correspondingly, so that predictions reflect the full rule set end to end.

• Complete coverage. Prediction reasons over the full documented rule set rather than a partial subset.
• Context-aware detection. Dependencies and table relationships inform predictions, reducing generic findings.
• Defensible output. A flagged issue traces to a documented business definition and can be substantiated to a client rather than presented as an unexplained model output.
• Earlier detection. Data defects are identified before load rather than discovered during reconciliation.

Dependency Hierarchy Displayed Alongside Analysis

The dependency object hierarchy is now displayed in the interface alongside the analysis, so that users see both the predicted issue and the objects it will affect. Establishing the extent of an issue is what determines remediation priority, and displaying it removes the manual step of tracing affected objects during root-cause analysis.

Deployable ETL Packages Generated from a Mapping

Code Cheetah generated extract logic, but no route existed from a generated script to an orchestrated, schedulable pipeline. Engineers authored orchestration manually, transferred scripts and configured connections per environment, a slow, repetitive process and a consistent source of error. From a mapping selection, Code Cheetah now produces a complete, self-contained ETL package for the extract layer, comprising orchestration, the bundled logic, configuration and deployment instructions.

• Minimal runtime requirement. The generated package executes locally with nothing beyond a container runtime.
• Source-aware generation. The generator adapts to the source system automatically, whether the extract remains within a single database engine or crosses from PostgreSQL or MySQL into the target platform.
• Reduced time to first load. The step from approved mapping to executing extract reduces from days of engineering to a generated package.
• Consistency across engagements. Every project receives the same pipeline structure, reducing the support burden associated with bespoke orchestration.
• Lower skill barrier. Delivery teams no longer require deep orchestration expertise to establish an extract.
• Designed for extension. The architecture provides a defined path to file, API and SaaS sources in a subsequent release.
• Script generation from Falcon Mapping. Scriptly reads directly from the approved Falcon Mapping and generates DDL and DML scripts scoped to the selected object and table, so scripts stay in sync with the governed mapping instead of being authored by hand.
• Language support and code review. SQL is currently the supported script language, with additional languages planned. Every generated script is followed by an automated code review pass before it is marked ready for use.

Transparent Lineage for Generated Transformation Logic

Generated transformation logic now carries visible lineage showing the joins, filter conditions and source tables that produced each result. Generated code is acceptable to a client only where it can be explained. Lineage allows a data owner to establish precisely how a target value was derived, which is the condition on which sign-off depends and the first evidence requested when a migrated figure is questioned.

• Joins and filters surfaced. Lineage shows the joins and filter conditions that produced each result, not just the final source table.
• Source traceability. A data owner can trace precisely how a target value was derived, the evidence typically requested first when a migrated figure is questioned.
• Sign-off ready. Explainable generated code is the condition most client sign-offs depend on, and lineage provides that explanation without engineering involvement.

Data Source Connection

Code Cheetah now uses the same data source connection model as Falcon Mapping across the Extract, Transform and Load stages of a pipeline, with a matching interface and consistent credential handling for each ETL stage.

• Single connection registry. Consultants no longer register the same connection twice across products.
• Automated lookup population. Lookup tables are populated automatically from the mapping document, including dependent tables reached through joins.
• Automatic reference recognition. Reference tables defined in the platform are recognised automatically within generated transformation logic.
• Configuration visibility. The ETL configuration view now displays the data source and its description for each of Extract, Transform and Load, making the connection a pipeline executes against evident without inspection.

Categorised Data Source and Integration Catalogue

Data sources are now organised into defined categories, Files & Formats, Databases, Cloud & API, and ERP & CRM, with each connector either available or explicitly identified as forthcoming.

• Available now. Excel and CSV; PostgreSQL, MySQL, SQL Server, CrateDB, DB2 and SAP HANA; generic API and Salesforce; Odoo ERP and Microsoft Dynamics AX.
• On the roadmap. SAP C4C, Microsoft Fabric, Microsoft Dynamics CRM and NAV, JD Edwards, Infor, Sage, Exact and SugarCRM.
• Commercial relevance. Source system coverage is among the first questions raised in every engagement qualification. Presenting a structured catalogue within the product, with the roadmap visible alongside current availability, supports that conversation directly.

Reference Tables Module

Transformations frequently require a value to be cross-referenced against a controlled list. These lists were previously maintained outside the product and entered wherever required, with no means of establishing which reference tables existed or of reusing one across mappings. A Reference Tables module is now provided in which these are created and maintained, and the tables created appear as a dropdown in the cross-reference column of the mapping module.

• Defined once, reused. Reference data is created centrally rather than re-entered per mapping.
• Error reduction. Selection from a controlled list rather than manual entry removes a category of transcription error.
• Visibility. Existing reference tables are discoverable without consulting the person who configured them.

A material proportion of v1.2.0 was invested in how BlueGecko is built and released rather than in functionality visible to end users. This work does not present in a demonstration, but it is what allows the capabilities above to be delivered predictably.

Template-Driven Module Visibility per Organisation

The platform supports engagements of materially different shape, one-off application migration, ongoing business-as-usual data operations, data warehouse consolidation. Presenting every module to every organisation made the product heavier than the engagement required and extended onboarding. Administrators now assign a configuration template to an organisation configuration, Application Migration, BAU or Data Warehouse Migration, and users are presented only the modules relevant to it.

• Faster onboarding. New users are presented a focused product rather than a full menu requiring explanation.
• Engagement alignment. What a team sees corresponds to the work they are contracted to perform.
• Extensible by configuration. Additional engagement types are added as templates without modification to application code.

Dedicated Admin Settings Module

User management and organisation management were located within Falcon Mapping, requiring administrators to enter a delivery product in order to administer the platform. Administration is now a separate module accessed from the BlueGecko landing page, available only to users holding Admin rights.

Database Access Governed by Directory Groups

Extending the identity work delivered in v1.1.0, access to the CrateDB analytical store is now controlled exclusively through Azure AD security groups. No individual user holds direct access to the database. Read-only, read/write and administrative access are each granted through group membership, and this was verified as part of the release. Client and third-party security reviews consistently establish whether individual database credentials exist; the position for BlueGecko is now uniformly negative across both the application and the analytical store.

Front-End Build Migration from Webpack to Vite

The React applications for both products have been migrated from Webpack to Vite. The existing Webpack configuration was analysed, dependencies and plugins requiring replacement were identified, compatibility issues were assessed, and the migration was executed against a documented plan with risks and validation steps recorded. The change is not visible in the product; its effect is on the speed at which the team can build, test and release, which subsequently presents as shorter delivery cycles.

130 defects in release scope, 2 Critical · 7 High · across all products

, together under 7% of the total, with the balance comprising medium-severity usability and presentation issues. The most significant defects are detailed below, being those that either blocked a workflow outright or produced results that appeared correct but were not.

Owl Sight, DQ / Issue Predict / PII Database Alignment

The three analytical modules, Data Quality (DQ), Issue Prediction (IP), and PII detection, were built with independent database schemas and connection strategies. This created inconsistencies across the BlueGecko Suite. In v1.1.0, all three are aligned to the database patterns established in Falcon Mapping.

• Shared Organisation entity. DQ, IP, and PII tables now reference the same Organisation entity as Falcon Mapping using identical foreign key conventions, enabling DQ profiling results to be directly linked to specific Falcon Mapping migration objects.
• Unified DataSource registry. A data source registered in Falcon Mapping’s admin panel is now immediately available in Owl Sight for DQ profiling. No duplicate registration. One source of truth.
• Audit column standardisation. All tables carry the standard BlueGecko audit columns ,
• Schema naming corrected. Tables standardised to PascalCase.

Per-Script Execution Generation & Context Refresh

A major enhancement to Code Cheetah's AI-powered script generation engine, enabling automated generation of deployment-ready DDL and DML scripts directly from approved Falcon Mapping documents.

• AI-powered script generation. Automatically generates standardized DDL and DML scripts by interpreting approved Falcon Mapping documents, eliminating manual SQL development while maintaining mapping consistency.
• Granular generation scope. Supports both Object-level and Table-level script generation, allowing teams to generate scripts for individual migration objects or complete database structures based on project requirements.
• Centralized script repository. Generated scripts are automatically persisted to a configured shared file repository, creating a reusable, version-controlled artifact library for deployment, review, and future migration projects.
• Mapping-driven consistency. Every generated script is derived from the latest approved mapping definitions, ensuring synchronization between business mappings and implementation while reducing transformation discrepancies.
• Accelerated migration delivery. Significantly reduces script development effort, standardizes implementation across projects, and enables repeatable, enterprise-scale migration execution.

BlueGecko AI Assistance for Code Generation

Code Cheetah now embeds the BlueGecko AI assistant directly inside the script editor. Engineers can ask the assistant for optimisation suggestions and logic recommendations while generating a script, instead of leaving the workspace to look up patterns or troubleshoot manually.

• Optimisation suggestions. The assistant reviews the current script and suggests performance and structure improvements.
• Logic recommendations. Contextual guidance on join conditions, filters and transformation logic based on the selected object and table.
• In-editor access. Available directly from the Script Editor toolbar, with no need to switch to a separate BlueGecko AI workspace.

Dynamic Column Schema, Mapping Document Restructure

In v1.0.0, the Mapping Document grid had fixed columns, Source Table, Source Column, Target Table, Target Column, Transformation Rule, Comments. These were hard-coded. Any additional column (e.g., a client-specific “Business Owner” or “Validation Rule” field) required a schema migration and redeployment.

• Configurable additional columns. Organisation admins can define custom mapping columns in the Admin panel. Stored in a dynamic-column model, no schema change or redeployment required.
• Runtime resolution. The Falcon Mapping grid resolves its column structure from the schema configuration at load time. Inline editing (
• Template alignment. Upload templates automatically reflect the dynamic columns configured for the organisation. Validation checks only configured columns, partial templates with only standard columns remain valid.
• Backwards compatible. All v1.0.0 mapping documents load correctly, standard columns always present; dynamic columns appear only when configured.

) works for all columns, standard and dynamic alike, including the auto-populated source system dropdown metadata.

BlueGecko AI, Mapping Assistance Quality Improvements

The AI mapping assistance module from v1.0.0 had several functional gaps in the UI layer. This work item consolidates targeted quality fixes across the BGAI module.

Data Source Module Enhancement

The Data Source module is where project administrators register source and target systems (Salesforce, SAP S/4, Oracle EBS, etc.) whose table/column metadata drives auto-populated dropdowns in the mapping editor. In v1.0.0, this module had critical UX gaps addressed here.

Centralised Identity & Access via Azure AD Groups

Previously, user access to Falcon Mapping, Code Cheetah, and Owl Sight was managed individually inside each product admin panel. With this feature, access is provisioned and revoked entirely through Azure Active Directory (Entra ID) security groups. IT administrators manage group membership in AD, BlueGecko reads the group claim at login and maps it to the corresponding RBAC role automatically. No manual user configuration inside BlueGecko is required.

• 18 AD Security Groups Provisioned, Naming Convention. BG_{ENV}_{PRODUCT}_{ROLE}
• ADMIN. Maps to BlueGecko Admin RBAC role, CanView + CanAdd + CanUpdate + CanDelete across all modules for that product. Reserved for project leads and platform administrators.
• RW (Read/Write). Maps to Developer and Consultant roles, CanView + CanAdd + CanUpdate on core operational modules. No access to admin, org management, or delete operations.
• RO (Read Only). Maps to Business User role, CanView on dashboards and reports, limited CanAdd on Upload and Object Config per the RBAC matrix.
• SVC (Service Account). Machine identity for backend API and pipeline processes (FM sync service, scheduler, AI inference). Not a human user role.
• App isolation enforced. BG_DEV_FM_ADMIN
• Environment isolation. DEV groups have no access to QA or PROD resources. PROD admin groups require PIM (Privileged Identity Management) approval for activation.
• Audit-ready naming. BG_PROD_FM_RW
• Scalable. Additional RW/RO groups can be added per product as user cohorts grow, without modifying BlueGecko application code.

members can access Falcon Mapping configuration, they cannot read Code Cheetah or Owl Sight secrets. Azure Key Vault access policies are configured per-group.

immediately communicates: production environment, Falcon Mapping product, read/write access, no cross-referencing internal role IDs needed in audit queries.

Login and Secure Access

Every Falcon Mapping session begins with a secure sign in. Users can sign in with single sign on through their organization's Microsoft Azure AD account, or with a traditional username and password. Both paths are supported today. Where multi factor authentication is required, it is enforced by your organization's own Azure AD and Entra ID security policies rather than a separate Falcon Mapping login step, so your existing security standards carry straight through. To protect against unattended sessions, Falcon Mapping automatically warns users with a live countdown before signing them out after a period of inactivity, giving them the choice to stay signed in or sign out immediately.

• Single sign on using each user's existing Microsoft Azure AD account, alongside traditional username and password sign in.
• Automatic inactivity session timeout warning, with Stay Signed In and Sign Out Now options.
• Multi factor authentication enforced through your organization's own Azure AD and Entra ID policies.

Business value. Security and trust start at the front door. Single sign on removes the burden of another password to manage, while the session timeout safeguard ensures an unattended screen never stays open indefinitely. This is enterprise grade behaviour from the very first screen.

Organization Selection, Configuration and Access

After signing in, users select the organization they are working in. Falcon Mapping supports many organizations from a single login, for example different business units or different clients. Falcon Mapping is delivered on a template driven, multi tenant architecture. Each organization's workspace is shaped around the customer's own data journey, so teams start from a proven baseline rather than a blank page. Access across that workspace is governed by role based access control (RBAC), so the right people can see and do exactly what they should, and nothing more. This is where Falcon Mapping empowers business teams to own their data governance, supported by our AI Agents, rather than depending on technical setup. Organizations are created and managed directly in Falcon Mapping. Each is given a name, description, and location, and is classified by type, PoC, Intake, or Production, so its lifecycle stage is always clear. Existing organizations can be searched, sorted, edited, or deactivated from a central management screen.

• Template driven, multi tenant workspace shaped around the customer's data journey.
• Role based access control (RBAC) across the organization workspace.
• Searchable, sortable organization list with pagination.
• Edit or deactivate an organization from a central management screen.

Business value. No two clients, or even two programmes for the same client, are at the same stage. Governing each organization's lifecycle and access from the moment it is onboarded keeps everyone clear on who can act and on whether the organization is still being evaluated (PoC), being brought on (Intake), or fully live (Production).

Dashboard

The Dashboard is the home base of Falcon Mapping, opening automatically once an organization is selected. Four summary tiles give an instant read on progress, Total Objects in Scope, Objects Not Started, Objects In Progress, and Objects Completed, each one clickable to filter the view further. Below the tiles, an Objects in Scope table lists every configured object with its current status, and a dedicated warnings table surfaces record level issues that need attention: data type mismatches, data truncation, or a mandatory field left unmapped. An interactive onboarding diagram also walks new users through the whole Falcon Mapping journey step by step, from organization setup through BlueGecko AI.

• A per organization list of every configured object with its status.
• Interactive progress dashboard with an overall mapping summary, an Objects in Scope status breakdown, and a record level warnings table.
• Filtering by organization and by object, so users can narrow the view to exactly what they need.

Business value. Project sponsors and business stakeholders need visibility without having to dig through technical detail. The Dashboard gives leadership a fast, clear answer to the question, where do things stand, at any point in the programme.

Data Sources, Connecting to Your Data

The Data Sources module is where Falcon Mapping connects to the systems that currently hold your business data. Eleven data source types are supported today, and connecting is a guided, step by step process rather than something that requires deep technical database expertise.

• SQL Server
• PostgreSQL
• MySQL
• CrateDB
• IBM Db2
• Microsoft Dynamics AX
• Odoo ERP
• Salesforce
• Generic API connection (URL, HTTP method, headers, authentication, and payload)
• Excel file upload (.xlsx)
• CSV file upload (.csv)

Business value. Programmes stall most often at the data access stage. By supporting a broad, guided set of connection types out of the box, Falcon Mapping removes the risk and delay that normally comes from custom, one off data extraction work, and new connectors continue to be added over time.

Upload, Bringing In Your Mapping Documents

The Upload module lets your team bring existing mapping documentation directly into Falcon Mapping rather than re entering it by hand. Today, Falcon Mapping accepts Excel (.xlsx) and CSV (.csv) files for mapping documents. When a new file is uploaded for an object that already has a mapping document, Falcon Mapping asks whether to override the existing mapping entirely or merge it, comparing and resolving differences before anything is finalised. Uploading a new version of an existing file shows a clear comparison view before the update is applied, and every version is tracked with its timestamp and the user who made the change. If a mapping file has other objects depending on it, Falcon Mapping blocks deletion and instead routes an approval request to an administrator, so nothing is removed unintentionally.

• Object based file management, one mapping file per object per organization, with a confirmation step before replacing an existing file.
• Override or merge handling when a mapping already exists, with differences resolved before finalising.
• Versioned overwrite with a side by side comparison view, plus a full audit trail of upload timestamp, user, and version.
• Deletion blocked and routed to an administrator for approval when other objects depend on the file.

Business value. Your team's existing planning work has value. Upload ensures that work is not thrown away, duplicated, or accidentally overwritten. It shortens the path from we already planned this to this is now live in the system, with safeguards at every step.

Mapping Module, Aligning Source and Target Fields

The Mapping Module is the core workspace of Falcon Mapping, where fields from your source system are matched field by field to the target system. Users can narrow their view with column visibility controls, showing just Source, Target, or Transformation columns, colour coded to match the familiar convention used in migration spreadsheets (green for target, blue for source, yellow for transformation). For fields that need a translated or looked up value, a Cross Reference Table dropdown lets users pick from a managed lookup list rather than typing values by hand. Before any mapping is approved, users can preview a read only sample of the first source records, so the effect of a mapping is clear before it is finalised. Every mapping change then goes through a formal approval step: it moves to Pending Approval, and a reviewer can approve or reject it, with any rejection reason automatically logged, and a full audit trail of who approved what.

• Hide and show mapping columns by category, Source, Target, or Transformation, colour coded to match standard migration spreadsheet conventions.
• Cross Reference Table dropdown for fields that require a looked up or translated value.
• Preview a read only sample of source records before approving a mapping.
• Formal approval workflow, a Pending Approval state, approve and reject actions, rejection reasons logged, and a full audit trail of approvals.

Business value. This is the step where data accuracy is won or lost. Getting field mappings right the first time, with clear preview tools and a formal approval trail, avoids costly rework, data errors, and delays later in the programme.

BlueGecko AI, Smarter Mapping, Faster

BlueGecko AI is the built in intelligent mapping assistant, built on a knowledge base covering seven ERP platforms: SAP S/4HANA, SAP Business One, SAP ECC, Microsoft Dynamics AX, Microsoft Dynamics 365, Odoo, and Infor. Rather than mapping every field manually, users can ask BlueGecko AI directly, for example, give me the mapping for Supplier, and receive a structured recommendation drawn from that knowledge base plus the organization's own uploaded mapping files. Every suggestion is reviewed by a person before it takes effect. Each answer can be rated with a quick thumbs up or thumbs down, and BlueGecko AI keeps a running chat history so users can revisit past conversations, both feeding directly into improving future recommendations. Within the Mapping Module, BlueGecko AI can also generate suggested transformation logic for a target field, which users can review and approve individually or in bulk.

• Recommendation engine with knowledge base filtering, matching against uploaded mapping files, and organization scoped responses.
• ERP knowledge bases covering SAP S/4HANA, SAP Business One, SAP ECC, Microsoft Dynamics AX, Microsoft Dynamics 365, Odoo, and Infor.
• Thumbs up and thumbs down feedback on every answer, plus a running chat history users can revisit.

Business value. BlueGecko AI turns one of the slowest, most manual parts of a data programme into a fast, guided review process, cutting down the hours spent on repetitive mapping work while keeping a human decision maker in full control of the outcome.

Task Management, Keeping the Programme On Track

Task Management gives your team a shared Kanban board, with New, In Progress, Closed, and Blocked columns, to track every task generated during the governance and migration process. Each task carries a priority (High, Medium, or Low) and a type (Bug, User Story, Feature, Task, or Epic). Tasks are also tagged with an Iteration (Dress Rehearsal 1 to 10) and an Environment (Dev, QA, UAT, SIT, or Production), so testing cycles and rehearsals are just as trackable as day to day work. Tasks support parent and child hierarchy, comments, and an activity feed, and can be filtered by status, priority, type, assignee, module, iteration, or environment. Views are available as a Dashboard summary, a drag and drop Board, or an editable List, and every task creation or update triggers an email notification to keep the right people informed.

• Kanban board with priorities, task types, parent and child hierarchy, comments, activity feed, and Dashboard, Board, and List views.
• Task type field, per person task count summary, email notifications on task changes, and object based tagging and filtering.
• Iteration (Dress Rehearsal 1 to 10) and Environment (Dev, QA, UAT, SIT, Production) tagging on every task, filterable on the board.

Business value. Programmes involve many moving parts across multiple people and test cycles, spanning different priorities, environments, and rehearsal stages. Task Management ensures nothing is missed: responsibilities stay clear, testing cycles and rehearsals are tracked with the same rigour as day to day work, and leadership always has an honest, up to date picture of progress.