From Guidewire Cloud Access to analytics-ready data

Use Guidewire Cloud Data Access to turn raw cloud exports into structured, usable data without custom pipelines or ongoing maintenance.
April 6, 2026

Insurers moving from on-premise Guidewire InsuranceSuite to Guidewire Cloud are making a strategic bet: better agility, faster upgrades, and a more modern data ecosystem.

A key part of that transition is Guidewire Cloud Data Access (CDA). For carriers accustomed to delayed data refreshes and limited visibility into historical changes, CDA is a significant upgrade. It continuously streams incremental change data from InsuranceSuite into your Amazon S3 bucket as Parquet files — all with near real-time delivery, exactly-once guarantees, and the latest schema. For data teams, it provides a far more modern foundation than legacy batch extracts or direct database access.

The challenge is that landing Guidewire data in S3 only gets you halfway there. The data still needs to be continuously ingested, mapped into reliable tables, adapted as schemas evolve, and delivered into the platforms business teams actually use.

What we hear from insurers:

  • "Our Guidewire data is in S3, but it's not usable by the business."
    Claims, underwriting, actuarial, and finance teams cannot work directly from raw Parquet files in a landing bucket. Until that data is structured and governed in a destination, the value of CDA stays trapped upstream.
  • "Every new entity or source pattern means more engineering work."
    What looks manageable at first quickly turns into a backlog of custom jobs, file mappings, and maintenance tasks that consume data engineering time week after week.
  • "Schema changes keep turning into pipeline failures."
    As Guidewire evolves (new fields, new entities, data type changes), brittle ingestion logic breaks. Dashboards go stale, reporting falls behind, and business users lose trust in the data.

Fivetran's Amazon S3 connector, powered by Dynamic Table Mapping, is designed to close these gaps, replacing weeks or months of custom pipeline work with a setup that takes minutes.

[CTA_MODULE]

What CDA gives you, and what it doesn't

Guidewire CDA exports follow a folder-based structure. Each InsuranceSuite entity gets its own folder, and inside that folder, timestamped subfolders contain the actual Parquet files. A typical CDA bucket looks like this:

s3://your-bucket/CDA/
├── tpolicy/
│   └── 1706745600000/
│       ├── part-00000.parquet
│       └── part-00001.parquet
├── tclaim/
│   └── 1706745600000/
│       └── part-00000.parquet
├── texposure/
│   └── 1706745600000/
│       └── part-00000.parquet
├── taccounttransaction/
│└── 1706745600000/
│       └── part-00000.parquet
├── tcoverage/
│   └── 1706745600000/
│       └── part-00000.parquet...
...

Each top-level folder (under the CDA/ prefix in the above example) represents a distinct entity from one of the InsuranceSuite centers, and each timestamped subfolder within it represents a batch of extracted data. Over time, this set of entities grows as Guidewire releases updates, you launch new products, or custom extensions come online. A typical CDA deployment has hundreds to thousands of these entity folders.

The traditional approach means writing and maintaining custom ingestion jobs, Spark scripts, or one-off mappings for each entity. For each new entity that appears, it's another engineering task, slowing down time-to-value for CDA. And when Guidewire adds or changes fields, it's another round of pipeline fixes, slowing things down even more.

How Fivetran’s Dynamic Table Mapping simplifies Guidewire CDA ingestion

Fivetran’s Dynamic Table Mapping lets you define a single regex that automatically maps Guidewire CDA files to destination tables based on folder structure. Rather than building and maintaining custom ingestion logic, you provide one rule per InsuranceSuite application (PolicyCenter, ClaimCenter, BillingCenter), and Fivetran automatically discovers, creates, and syncs every matching entity, including ones that don't exist yet.

For a typical Guidewire CDA setup:

Pattern: (?<table>[^/]+)/\d+/.*\.parquet

This pattern tells Fivetran: "The table name is the top-level folder (e.g. tpolicy, tclaim, taccounttransaction). Ignore the timestamp subfolder and parquet filenames." For a step-by-step walkthrough of how to write and validate these patterns, see our Dynamic Table Mapping tutorial.

What Fivetran creates automatically:

Path in S3 Destination table
tpolicy/1706745600000/part-00000.parquet tpolicy
tclaim/1706745600000/part-00000.parquet tclaim
texposure/1706745600000/part-00000.parquet texposure
taccounttransaction/1706745600000/part-00000.parquet taccounttransaction
tcoverage/1706745600000/part-00000.parquet tcoverage

When a new entity folder appears, say tcyberliability/ after a new product launch, Fivetran detects the new parquet files, then automatically creates the tcyberliability table and starts syncing. No reconfiguration. No engineering ticket. No delay.

Pair that with Fivetran's automatic schema evolution, where new columns, data type changes, and structural updates are handled without manual intervention, and you have an ingestion layer that keeps up with Guidewire without constant engineering attention.

What this means for insurers

As Guidewire encourages carriers to move to the cloud, insurers have an opportunity to modernize their data architecture in parallel with their core system transformation. Fivetran with Dynamic Table Mapping helps on several fronts:

  • Accelerates time-to-value. Setup for each InsuranceSuite application (PolicyCenter, ClaimCenter, BillingCenter) takes minutes, with one pattern covering all of that application's entities. Move from "the data technically exists in S3" to "the business can actually use it" in minutes, not months.
  • Reduces engineering overhead and risk. New entity folders are discovered and synced automatically, with zero manual intervention. Schema changes propagate on their own. No pipeline failures, no fire drills.
  • Enables high-value use cases faster. Get claims, underwriting, actuarial, finance, and fraud teams working with timely, analytics-ready Guidewire data without waiting on data engineering backlogs.
  • Standardizes your cloud data foundation. Apply the same automated, governed ingestion approach you use for the rest of your stack to one of the most critical systems in the insurance enterprise.

This translates to days of saved setup time upfront and dozens of hours saved annually on maintenance, freeing engineering capacity to deliver business value.

Where to go from here

If you're already using Guidewire Cloud Data Access or planning a migration from on-premise InsuranceSuite to Guidewire Cloud, this is the right time to define an ingestion pattern that will scale.

Fivetran's Amazon S3 connector with Dynamic Table Mapping provides a low-friction, automated path from raw CDA files in S3 to analytics-ready Guidewire data in your warehouse or lake, without the recurring burden of custom ingestion pipelines.

Get started with Fivetran's S3 connector →

If you'd like a tailored walkthrough of how this could work in your environment, reach out to your Fivetran account team. We'd be happy to help you turn Guidewire Cloud data into a reliable, always-on input for analytics, operations, and AI.

[CTA_MODULE]

Data insights
Data insights

From Guidewire Cloud Access to analytics-ready data

From Guidewire Cloud Access to analytics-ready data

April 6, 2026
April 6, 2026
From Guidewire Cloud Access to analytics-ready data
Use Guidewire Cloud Data Access to turn raw cloud exports into structured, usable data without custom pipelines or ongoing maintenance.

Insurers moving from on-premise Guidewire InsuranceSuite to Guidewire Cloud are making a strategic bet: better agility, faster upgrades, and a more modern data ecosystem.

A key part of that transition is Guidewire Cloud Data Access (CDA). For carriers accustomed to delayed data refreshes and limited visibility into historical changes, CDA is a significant upgrade. It continuously streams incremental change data from InsuranceSuite into your Amazon S3 bucket as Parquet files — all with near real-time delivery, exactly-once guarantees, and the latest schema. For data teams, it provides a far more modern foundation than legacy batch extracts or direct database access.

The challenge is that landing Guidewire data in S3 only gets you halfway there. The data still needs to be continuously ingested, mapped into reliable tables, adapted as schemas evolve, and delivered into the platforms business teams actually use.

What we hear from insurers:

  • "Our Guidewire data is in S3, but it's not usable by the business."
    Claims, underwriting, actuarial, and finance teams cannot work directly from raw Parquet files in a landing bucket. Until that data is structured and governed in a destination, the value of CDA stays trapped upstream.
  • "Every new entity or source pattern means more engineering work."
    What looks manageable at first quickly turns into a backlog of custom jobs, file mappings, and maintenance tasks that consume data engineering time week after week.
  • "Schema changes keep turning into pipeline failures."
    As Guidewire evolves (new fields, new entities, data type changes), brittle ingestion logic breaks. Dashboards go stale, reporting falls behind, and business users lose trust in the data.

Fivetran's Amazon S3 connector, powered by Dynamic Table Mapping, is designed to close these gaps, replacing weeks or months of custom pipeline work with a setup that takes minutes.

[CTA_MODULE]

What CDA gives you, and what it doesn't

Guidewire CDA exports follow a folder-based structure. Each InsuranceSuite entity gets its own folder, and inside that folder, timestamped subfolders contain the actual Parquet files. A typical CDA bucket looks like this:

s3://your-bucket/CDA/
├── tpolicy/
│   └── 1706745600000/
│       ├── part-00000.parquet
│       └── part-00001.parquet
├── tclaim/
│   └── 1706745600000/
│       └── part-00000.parquet
├── texposure/
│   └── 1706745600000/
│       └── part-00000.parquet
├── taccounttransaction/
│└── 1706745600000/
│       └── part-00000.parquet
├── tcoverage/
│   └── 1706745600000/
│       └── part-00000.parquet...
...

Each top-level folder (under the CDA/ prefix in the above example) represents a distinct entity from one of the InsuranceSuite centers, and each timestamped subfolder within it represents a batch of extracted data. Over time, this set of entities grows as Guidewire releases updates, you launch new products, or custom extensions come online. A typical CDA deployment has hundreds to thousands of these entity folders.

The traditional approach means writing and maintaining custom ingestion jobs, Spark scripts, or one-off mappings for each entity. For each new entity that appears, it's another engineering task, slowing down time-to-value for CDA. And when Guidewire adds or changes fields, it's another round of pipeline fixes, slowing things down even more.

How Fivetran’s Dynamic Table Mapping simplifies Guidewire CDA ingestion

Fivetran’s Dynamic Table Mapping lets you define a single regex that automatically maps Guidewire CDA files to destination tables based on folder structure. Rather than building and maintaining custom ingestion logic, you provide one rule per InsuranceSuite application (PolicyCenter, ClaimCenter, BillingCenter), and Fivetran automatically discovers, creates, and syncs every matching entity, including ones that don't exist yet.

For a typical Guidewire CDA setup:

Pattern: (?<table>[^/]+)/\d+/.*\.parquet

This pattern tells Fivetran: "The table name is the top-level folder (e.g. tpolicy, tclaim, taccounttransaction). Ignore the timestamp subfolder and parquet filenames." For a step-by-step walkthrough of how to write and validate these patterns, see our Dynamic Table Mapping tutorial.

What Fivetran creates automatically:

Path in S3 Destination table
tpolicy/1706745600000/part-00000.parquet tpolicy
tclaim/1706745600000/part-00000.parquet tclaim
texposure/1706745600000/part-00000.parquet texposure
taccounttransaction/1706745600000/part-00000.parquet taccounttransaction
tcoverage/1706745600000/part-00000.parquet tcoverage

When a new entity folder appears, say tcyberliability/ after a new product launch, Fivetran detects the new parquet files, then automatically creates the tcyberliability table and starts syncing. No reconfiguration. No engineering ticket. No delay.

Pair that with Fivetran's automatic schema evolution, where new columns, data type changes, and structural updates are handled without manual intervention, and you have an ingestion layer that keeps up with Guidewire without constant engineering attention.

What this means for insurers

As Guidewire encourages carriers to move to the cloud, insurers have an opportunity to modernize their data architecture in parallel with their core system transformation. Fivetran with Dynamic Table Mapping helps on several fronts:

  • Accelerates time-to-value. Setup for each InsuranceSuite application (PolicyCenter, ClaimCenter, BillingCenter) takes minutes, with one pattern covering all of that application's entities. Move from "the data technically exists in S3" to "the business can actually use it" in minutes, not months.
  • Reduces engineering overhead and risk. New entity folders are discovered and synced automatically, with zero manual intervention. Schema changes propagate on their own. No pipeline failures, no fire drills.
  • Enables high-value use cases faster. Get claims, underwriting, actuarial, finance, and fraud teams working with timely, analytics-ready Guidewire data without waiting on data engineering backlogs.
  • Standardizes your cloud data foundation. Apply the same automated, governed ingestion approach you use for the rest of your stack to one of the most critical systems in the insurance enterprise.

This translates to days of saved setup time upfront and dozens of hours saved annually on maintenance, freeing engineering capacity to deliver business value.

Where to go from here

If you're already using Guidewire Cloud Data Access or planning a migration from on-premise InsuranceSuite to Guidewire Cloud, this is the right time to define an ingestion pattern that will scale.

Fivetran's Amazon S3 connector with Dynamic Table Mapping provides a low-friction, automated path from raw CDA files in S3 to analytics-ready Guidewire data in your warehouse or lake, without the recurring burden of custom ingestion pipelines.

Get started with Fivetran's S3 connector →

If you'd like a tailored walkthrough of how this could work in your environment, reach out to your Fivetran account team. We'd be happy to help you turn Guidewire Cloud data into a reliable, always-on input for analytics, operations, and AI.

[CTA_MODULE]

See Fivetran in action.
Get a demo
Ready to get started with Fivetran?
Start a free trial
Topics
Share

Related blog posts

Start for free

Join the thousands of companies using Fivetran to centralize and transform their data.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.