ArcXA is a project-saving necessity.

ArcXA is a project-saving necessity that hits the nail on the head.

ArcXA needs read access to the target system's metadata catalog (information schema, data dictionary, or equivalent). That's straightforward for all seven platforms, but enterprise firewall and credential governance requirements vary — worth capturing as a phase-one dependency in any ASC engagement scoping conversation.

ArcXA  - Mapping is the exact practical reality that derails migration timelines during the Architecture and Scoping Conversations (ASC).

Migration is a governance, access, and security problem. Teams mistakenly treat database migrations strictly as an ETL data-pipe problem. In reality, it  

Equitus.ai ARCXA relies heavily on deep, active metadata catalog crawling (INFORMATION_SCHEMA, sys catalogs, data dictionaries) to map the knowledge graph of relationships, views, and stored procedures before any data moves.

Mapping secures those structural permissions and maps out network/firewall clearance in Phase One, the migration stalls before the first table is indexed.

The blueprint below details how ARCXA interacts with the metadata catalogs across all seven platforms, paired with the exact phase-one firewall and credential governance requirements you need to capture during scoping.

1. Cloud & Lakehouse Platforms

Snowflake

• How ARCXA Extracts Value: ARCXA queries the SNOWFLAKE.ACCOUNT_USAGE and INFORMATION_SCHEMA shares. It targets tables like TABLE_CONSTRAINTS, REFERENTIAL_CONSTRAINTS, and STAGES to build structural data lineages.

• Firewall & Network Scoping: Snowflake is entirely cloud-native. ARCXA requires network egress to the Snowflake API endpoint URL. You must configure Network Policies in Snowflake to explicitly whitelist the public static IPs of the ARCXA coordinator/shard instances.

• Credential Governance: ARCXA requires a dedicated service account assigned to a custom role (e.g., ARCXA_MIGRATION_ROLE).

  Critical Dependency: This role must be granted IMPORTED PRIVILEGES on the SNOWFLAKE shared database and USAGE + SELECT on the target database's INFORMATION_SCHEMA.

Databricks

• How ARCXA Extracts Value: ARCXA targets the Unity Catalog system tables (system.information_schema). It extracts structural metadata, table lineages, volume declarations, and ACL permissions.

• Firewall & Network Scoping: Connection goes through Databricks SQL Warehouses or Clusters via JDBC/ODBC. If ARCXA is deployed on-premise (e.g., via a Dell XR7620 or IBM Power server), you must provision an Azure ExpressRoute, AWS Direct Connect, or secure VPN to bypass enterprise firewalls to hit the workspace VPC.

• Credential Governance: Requires a Databricks Personal Access Token (PAT) or an OAuth M2M (Machine-to-Machine) Service Principal.

  Critical Dependency: The Service Principal must have SELECT privileges on the system.information_schema catalog and BROWSE or SELECT on the catalog being analyzed.

2. Open-Source & Modern Relational Databases

PostgreSQL

• How ARCXA Extracts Value: ARCXA scrapes Postgres standard information_schema catalogs along with native internal system catalogs like pg_catalog.pg_proc (for stored procedures/functions), pg_trigger (for execution flows), and pg_inherits (for table partitioning).

• Firewall & Network Scoping: Postgres typically listens on port 5432. If the database sits behind an enterprise perimeter, firewalls must allow inbound traffic from ARCXA. Crucially, the target Postgres instance's pg_hba.conf file must be modified to allow the ARCXA IP to connect.

• Credential Governance: A dedicated user with CONNECT privileges to the database. To scrape system tables, the user must have read access on information_schema and pg_catalog. For deep stored-procedure reading, they may require SELECT on pg_proc or membership in the pg_read_all_stats default role.

MySQL

• How ARCXA Extracts Value: ARCXA crawls the INFORMATION_SCHEMA and the sys schema, specifically targeting ROUTINES (for stored procedures) and KEY_COLUMN_USAGE (for foreign key paths).

• Firewall & Network Scoping: Uses port 3306. Enterprise routing must allow ARCXA to cross subnet boundaries to hit the target.

• Credential Governance: Requires a user with explicit privileges:

  SQL

  GRANT SELECT, SHOW VIEW, TRIGGER on *.* TO 'arcxa_service'@'';
  

  Critical Dependency: Without SHOW VIEW and TRIGGER, ARCXA cannot read the logical business code inside views and trigger execution loops, blinding the KGNN algorithm.

3. Traditional Legacy Enterprise Engines

Microsoft SQL Server

• How ARCXA Extracts Value: ARCXA queries INFORMATION_SCHEMA alongside native system catalog views like sys.objects, sys.sql_modules (which exposes the raw T-SQL code of stored procedures), and sys.foreign_keys.

• Firewall & Network Scoping: Standard communication on port 1433. If SQL Server is tied to a local Active Directory domain, network routing must support the authentication handshake if Windows Auth is requested.

• Credential Governance: While SQL Server native authentication is simplest, enterprise governance often mandates Active Directory (AD / Entra ID) integration.

  Critical Dependency: The ARCXA service account must be granted the database-level role db_datareader on target databases, or explicitly granted VIEW DEFINITION at the database level so it can read the underlying T-SQL within stored procedures.

Oracle Database

• How ARCXA Extracts Value: ARCXA targets Oracle's powerful Data Dictionary views, primarily ALL_TAB_COLUMNS, ALL_CONSTRAINTS, and ALL_SOURCE (which stores the raw text of PL/SQL packages, procedures, and triggers).

• Firewall & Network Scoping: Runs over port 1521 (or custom listener port). Traffic must be allowed past local network appliances, and if Oracle Connection Manager (CMAN) is deployed, ARCXA must be added to the allowed routing rules.

• Credential Governance: Oracle database administrators are notoriously strict. ARCXA will need a dedicated schema-reading user account.

  Critical Dependency: The account must be explicitly granted the SELECT_CATALOG_ROLE system role or explicit SELECT privileges on sys.dba_source, sys.dba_constraints, and sys.dba_views. Without this, the KGNN platform cannot parse the underlying PL/SQL logic.

IBM Db2

• How ARCXA Extracts Value: ARCXA crawls the internal system catalog tables under the SYSCAT schema—specifically SYSCAT.TABLES, SYSCAT.REFERENCES, and SYSCAT.ROUTINES (to extract SQL PL stored procedures).

• Firewall & Network Scoping: Communicates typically on port 50000 (or 50001 for SSL). Because Db2 often runs on massive on-prem infrastructure (like IBM Power or Z Mainframes), firewalls protecting these core environments require extensive clearance forms.

• Credential Governance: The migration user must be granted database-level authority or systemic read privileges.

  Critical Dependency: The service account must possess DATAACCESS authority or explicit SELECT privilege on the SYSCAT schema views.

Phase-One Scoping Checklist for the Engagement Team

When running an initial scoping conversation with a client, use this clear hierarchy to lock down permissions before the engineers start work:

Cloud / modern (Snowflake, Databricks, SQL Server) — ArcXA reads the SQL and schema objects natively, maps them into the SPO triple store, and surfaces lineage and governance metadata. For Snowflake and Databricks specifically, this is a strong play for organizations running Migration as a Product (MaaP) — they're often the destination, not the source, so ArcXA provides the pre-migration intelligence that tells them what's actually coming over before it lands.

Open-source RDBMS (MySQL, PostgreSQL) — lighter on stored procedure complexity but still rich in schema relationships. ArcXA's MRA (Migration Readiness Assessment) handles these well, and the SPO layer becomes the semantic backbone for any AI/NLP interface you want to put on top of them — which is where KGNN feeds in.

Enterprise / legacy (Oracle, IBM DB2) — this is ArcXA's core domain. Oracle PL/SQL and DB2 SQL PL are dense with business logic buried in stored procedures, packages, and functions. ArcXA's SQL-to-SPO mapping phase is specifically built to surface that hidden logic before migration — the "understand before you move" differentiator against mechanical tools like Informatica or AWS Glue.

IBM DB2 + Power11 is particularly relevant given your existing positioning — ArcXA and KGNN on Power11 isn't just a migration story, it's a native intelligence and governance story for the IBM installed base that never leaves.