Accelerating SAP Migrations with Foundry and AIP

Mapping the Palantir Octopus model to an SAP ECC → S/4HANA migration

Time is running out for organisations still on ECC to migrate to SAP’s S/4HANA,. While legacy migration models can, in theory, still help with getting this done before costly maintenance fees kick in, there’s a better way that even SAP itself has cosigned.

Enter: Palantir's , Octopus model, an AI-led migration approach where a central ‘brain’ coordinates six specialised ‘arms’.

This document maps what that looks like in practice: what the brain does, what each arm does, which Foundry (Palantir's data and operations platform) and AIP (its AI layer) capabilities support each part, and where the model stops.

If cutting technical migration costs and time by 70% sounds appealing, this is the blueprint.

The Brain

The brain takes shape as an AIP Hivemind — an application that holds the migration's unified context, and coordinates work across each of the six arms. Each context piece is held by specific platform capabilities:

• Legacy structures: The source SAP tables, their schemas, and how they relate to each other. These are held as the source datasets and virtual tables themselves, with Data Lineage,Foundry's live graph of how every dataset connects to every transform and downstream use, providing the cross-pipeline view, walking forwards for impact analysis) and backwards for root-cause tracing (e.g. when a validation error occurs).

• Target requirements : The post-migration business model. This is formed by the Ontology, Foundry's business-readable model layer, which names entities in business terms (e.g. Material, BusinessPartner, JournalEntry) independent of the source SAP table.

• Business rules: Mapping logic, validation rules, and custom code that govern correctness. These are held in Health checks and Data expectations (declarative data-quality rules) at the pre-Ontology layer, and in AIP Logic and Foundry Functions (no-code LLM-driven and code-based logic over the Ontology, respectively) at the Ontology layer. All are versioned in the platform and monitored at scale through Data Health which provides a rolled-up view across every health check.

• Compliance standards: The customer's regulatory and policy obligations, that the migrated system must meet such as GDPR, SOX, or GxP. These are held as ontology objects and in Notepads (object-aware documents) alongside the data, so each transform and Ontology edit can be checked against the standards that apply. The platform's Audit logs, permissions, and markings (row- and column-level access controls) enforce the resulting controls.

• Delivery goals: The migration's scope, milestones, and workstream gates, are held as Ontology objects (e.g. Workstream, MigrationGate) alongside the business entities, so the same context covers both what is being migrated and when each piece must land.

As a result, narrative context, such as mapping decisions, open questions, SME inputs etc., accumulates alongside the code and data in Notepads, so the why of a transform sits next to the what. The AIP Hivemind is also bidirectional, so feedback from SME Interfaces (arm 5, which you’ll read about below) and corrections from Upload & Execution (arm 6) flow back into it, keeping the unified context current as each arm pulls context and pushes outputs.

The Arms

Each arm is a stage of the migration. AI FDE, Palantir's AIP-powered agent that operates Foundry on behalf of a human Forward Deployed Engineer (FDE), does the engineering work in several of the arms.

Arm 1 — Data Understanding

This arm connects to sources, interprets schemas, and parses legacy documents and data dictionaries.

• Connect to sources → A data connection agent running on a host inside the corporate network, connects to Foundry Sources (its catalogue of external-system connections). For SAP,an ABAP add-on, the Foundry Connector 2.0 for SAP Applications, is installed directly on the SAP application server via SAINT (SAP Add-On Installation Tool) and exposes data over HTTPS REST. Thedata connection agent acts as the network proxy between SAP and Foundry, initiating outbound HTTPS to Foundry, so no inbound port on the corporate network is required (legacy SAP systems that don't meet the Connector's prerequisites use the older SAP Remote Agent instead). Batch syncs are used for master data, with Change Data Capture (CDC) for high-volume transactional tables.

• SAP data integration → HyperAuto (SDDI) offers out-of-the-box understanding of the standard SAP data model, including —table relationships, schema mapping, and pre-canned cleansing transforms (null handling, type fixes, whitespace), for common objects (MARA, LFA1, KNA1, BSEG, EKKO). HyperAuto removes the need for most of the bespoke pipeline work that’s usually required, for anything that fits the standard SAP shape.

• Interpret schemas → For the work HyperAuto's pre-canned models don't cover, such as custom SAP Z-tables, customer-specific extensions, and migration-specific analysis, AI FDE, an interactive, conversational agent which completes Foundry operations on the human engineer’s behalf, profiles raw extracts, proposes join keys, value distributions, and likely PII columns. For example: profiling LFA1 and KNA1 for Business Partner consolidation, returns tax ID, DUNS, and a name + address fuzzy match as candidate match keys.

• Parse legacy docs and data dictionaries → Data dictionaries, ABAP source dumps, and tribal-knowledge documents are ingested as datasets and parsed into structured mappings, using AI FDE.

Arm 2 — Code Interpretation

This is where the model translates legacy ABAP / custom code to extract business logic.

• Triage at scale → AI FDE is used to produce a structured map of every piece of custom code - the Z-inventory of Z-tables, Z-reports, user exits, BAdIs (SAP's various flavours of custom extension code) - classifying each routine (retire, port, or refactor) with rationale.

• Translate and port → Given an exported ABAP routine, AI FDE parses it into a structured description of inputs, outputs, branches, and side effects. It drafts the equivalent as a Code Repositories transform (PySpark, the default for dataset-level logic) or for per-object action-triggered logic, a Foundry Function in TypeScript or Python. Then it runs a preview and opens a pull request. The human FDE reviews, refactors, and adds test cases.

• Validate parity → AIP Evals (a test harness that grades LLM-driven outputs against curated inputs) is used for the LLM-driven port of any non-deterministic logic. Side-by-side comparison through a custom application is built on the Ontology for deterministic cases. Once parity is verified, the legacy Z-routine is retired at cutover, and the new transform (or Function) inherits documentation captured during the port, including test cases, mapping rationale, and decision notes in Notepads.

Arm 3 — Transformation

This arm maps legacy values to new standards, remapping hierarchies and organisational structures accordingly.

• No-code mapping → Pipeline Builder (Foundry's visual, no-code pipeline tool) is used for expert-led work, e.g. transferring legacy MTART codes to a new global material taxonomy.

• Complex transformation → Python transforms (PySpark) authored in Code Repositories (Foundry's built-in git, PR and CI), is used for migration-specific logic on top of HyperAuto's cleaned outputs, aggregating BSEG plus the CO ledgers into a candidate ACDOCA-shape dataset, or unioning LFA1 and KNA1 records with a similarity score.

• Safe iteration → Global Branching enables branch-and-merge across the whole Palantir platform, end-to-end, so changes can be staged and reviewed before they touch production. Schedules maintain refresh cadence during a long-running migration.

• Hierarchy remapping → versioned mapping datasets that translate legacy hierarchies, including cost centres, plants, and legal entities, into the target structure. When the business changes the target mid-programme, for example because a plant closes or two entities consolidate, the SME updates the mapping on a Global Branch and sees in Data Lineage exactly which materials, POs, or journal entries will move before approving the change.

AI FDE does the leg work, drafting Pipeline Builder graphs, Python transforms, and mapping datasets, for human FDE review on a Global Branch before merge.

Arm 4 — Validation

This is where continuous validation metrics and real-time error identification comes in.

• Continuous validation → Health checks defined by data expectations on each output, monitored at workstream level through Data Health. For each JournalEntry, Material, or BusinessPartner produced, checks cover source-to-target reconciliation, withperiod balances reconcile to the cent; business rule conformance, ensuring open POs reference valid plants and that material types match the new taxonomy, and referential integrity for example, so every BP reference resolves, checking that every cost centre exists.

• Real-time error identification → failed records carry a structured reason code surfaced via an Ontology property, e.g. reconciliation_status: RECONCILED | DELTA | UNRESOLVED. A scoreboard tracks aggregate pass rate per workstream; cutover gates are typically set at 99.99% reconciliation for finance.

• LLM rule testing → SME-authored Logic functions, e.g. fuzzy-conformance rules, or entity-match heuristics, are tested against curated cases using AIP Evals, before joining the production validation set.

Validation reruns whenever a transform changes, for example when an FDE adjusts a filter on a branch or an SME confirms a merge, new failures appear in the SME queue within minutes.

Arm 5 — SME Interfaces

Natural language corrections and business rule definitions come into play.

• Reconciliation interfaces → custom applications are built on the Ontology in Workshop (Foundry's no-code app builder). These are typically one per workstream, with drill-down from aggregate metrics into the specific objects flagged for review.

• Audited corrections → Changes users make to Ontology objects are audited via action types. For example, a Confirm BP Merge action creates a unified BusinessPartner record from a candidate vendor/customer pair with a merge_rationale property. Function-backed actions handle multi-object remediation atomically, e.g. splitting a wrong merge and applying a substitution across many materials.

• Conversational analytics → AIP Analyst is a natural-language interface that works across the whole Ontology to return answers with the underlying query visible and editable. Ad-hoc questions, for example, "how many materials still require review in the new London plant?", get a live answer. Used by SMEs, finance leads, and steering committee members alike.

• Business rule definition → SMEs use AIP Logic's no-code block environment to define LLM-powered rules over the Ontology, e.g. flagging open POs where a ship-to plant rule is no longer valid. An FDE reviews and ships the resulting Logic function.

Every SME action - confirm, reject, override, define-rule - is captured as feedback into the brain.

Arm 6 — Upload & Execution

The final step – preparing validated data for S/4HANA and propagating corrections.

• Write to S/4HANA → Foundry exposes prepared data through action webhooks - outbound requests fired when an action runs, for real-time push, e.g. on approval of a BP merge; or scheduled exports for batches, e.g. LTMC-format files. SAP receives via BAPI, OData services, or LTMC staging tables, SAP's standard inbound paths (function-call, REST-style, bulk-load respectively), depending on the object type. For example: approved Business Partners export nightly in LTMC format, with a real-time webhook fired on each newly approved merge.

• Parallel-run → Foundry maintains live connections to both legacy and target systems through the parallel-run period, so business operations don't stop on cutover weekend.

• Propagate corrections → if an S/4HANA upload fails or downstream business validation flags a problem, that information is captured back in Foundry, the relevant Ontology object is marked, and the SME queue picks it up, closing the loop back to the brain.

AI FDE — operating Foundry through natural language

AI FDE is the AIP-powered agent that carries the engineering load across all arms. It operates Foundry on the human FDE's behalf, reading Data Lineage, writing transforms such as Python in Code Repositories, or graphs in Pipeline Builder, editing the Ontology, drafting Foundry Functions and AIP Logic rules, and validating its own changes against CI checks. All the while, records of decisions and open questions are kept in object-aware Notepads.

AI FDE proposes the work on a Global Branch for pipeline or Ontology changes, or a code repository’s pull request for transforms and functions. The human FDE reviews the technical approach, the affected SME reviews the business impact, and the branch or PR merges to production.

AI FDE does not choose what to ask, in what order, or whether a proposed mapping is correct - the human FDE always stays in control of those decisions.

Worked example — closing the loop on a reconciliation failure

This example case study exercises arms 4 (Validation), 3 (Transformation) and 5 (SME Interfaces). As you’ll see, at week 8 of this SAP S/4HANA migration, reconciliation surfaces a €184,000 gap on one cost centre between the source ECC balance and its transformed equivalent in Foundry.

Total: approximately 85 minutes. In a traditional migration the equivalent diagnostic typically takes one to two weeks.

What Foundry and AIP don't solve

Foundry and AIP compress the data and engineering portion of an SAP migration. However, they do not address broader change management requirements. Some factors remain your responsibility, which should help focus priorities while Palantir technology does the rest:

• Target operating model decisions. Which legal entities consolidate, which plants close, who owns each piece of master data. The platform reflects these decisions; it does not make them.

• Cross-business-unit reconciliation. When multiple geographies or business units hold conflicting versions of the same data, the platform exposes both with provenance but does not adjudicate.

• Change management and training. End-user adoption of the new system remains a separate workstream.

• Programme governance. Steering committee operation, workstream-level political mechanics, and gate management.

• Workstream prioritisation. Which workstream to attack, whether a proposed mapping is correct, what to merge and when - these are still human decisions, supported by the pod's standard cadences.

Without these surrounding activities in place, the platform accelerates work without changing whether the work was correctly scoped.

What next?

Valliance is an AI-native team with deep SAP expertise. We build bespoke teams with the exact skills each enterprise needs for success. The majority of our fees are charged only on successful technical migration, so we have no interest in finding complexity, but every interest in removing it.

We'd love to talk to you about how we can help you deploy Palantir's Octopus model to reduce S/4 technical migration time by 70%. Request your independent SAP migration assessment to find out more. 

Capability glossary

References: AI FDE · AIP overview · AIP Analyst · AIP Logic · Foundry Functions · AIP Evals · Data Lineage · Ontology · Action types · Action webhooks · Code Repositories · Pipeline Builder · Workshop · Insight · Python transforms · Global Branching · Data Connection agent · SAP architecture · Foundry Connector 2.0 for SAP · SAP Remote Agent (legacy) · HyperAuto (SDDI) · Health checks · Data expectations · Data Health · Notepad · Ontology architecture.