How to export data from Warehouse to Lakehouse in Microsoft Fabric: step by step

João Barros 21 de August de 2026 5 min read

This guide shows how to export data from a Warehouse to a Lakehouse in Microsoft Fabric in a controlled way, preserving the schema and applying light transformations. This task is useful when you need to consolidate data in a Lakehouse for Power BI analysis, reduce Warehouse storage costs, or prepare data for downstream ETL pipelines. The goal is to have a reliable process that preserves types, permissions and allows simple validation after the copy.

Prerequisites

An account with access to a workspace in Microsoft Fabric and read permissions on the Warehouse and write permissions on the Lakehouse. Ideally the identity used has minimal RBAC permissions for security.
A Warehouse with a sample table available (for example, 1M rows, ~500 MB) to test before larger loads.
A Lakehouse created with sufficient space and write permissions; check OneLake quotas (for example, 100 GB free for tests) and the abfss path where the Parquet files will be stored.
Basic knowledge of SQL/T-SQL and access to the Warehouse SQL Editor or T-SQL Notebooks to run queries and load scripts.

Step 1: Plan the schema mapping

Before copying data, compare the table schema in the Warehouse with the target table in the Lakehouse. Do a small inventory: column names, types (BIGINT vs INT, VARCHAR vs NVARCHAR), nullability and data types with decimal precision. Decide whether to keep the same column names, change types for compatibility (for example, convert FLOAT to DECIMAL(18,4)), or add audit columns such as load_timestamp, source_system or batch_id. For large tables, consider partitioning by date (for example, partition_date) for smaller Parquet files and faster queries.

Step 2: Create the target table in the Lakehouse

Create the table in the Lakehouse with the desired schema. In Microsoft Fabric, use the Warehouse SQL Editor (or a T-SQL Notebook) pointing to the Lakehouse OneLake path. A simple method is to create an external table pointing to a Lakehouse directory. If you expect incremental loads, plan partitioning by a column such as load_date to reduce files and improve read performance in Power BI.

-- Exemplo T-SQL para criar uma tabela externa parquet no Lakehouse
CREATE EXTERNAL TABLE lakehouse_schema.target_table (
  id BIGINT,
  name VARCHAR(200),
  amount DECIMAL(18,2),
  load_timestamp DATETIME2
)
WITH (
  LOCATION = 'abfss://@.dfs.core.windows.net/lakehouse/path/target_table/',
  FILE_FORMAT = (TYPE = PARQUET)
);

Step 3: Extract and transform data from the Warehouse

Run a query in the Warehouse to select and transform the data. Here you can filter (for example, is_active = 1), aggregate or convert types for compatibility with the Lakehouse. Add an audit column if needed. For medium volumes (100k–1M rows) in-memory transformation is fast; for tens of millions consider transforming in batches to reduce memory usage. Practical transformation examples: normalize text with UPPER/LOWER, round decimals and convert time zones to UTC.

-- Exemplo de SELECT transformador no Warehouse
SELECT
  id,
  UPPER(name) AS name,
  CAST(amount AS DECIMAL(18,2)) AS amount,
  SYSUTCDATETIME() AS load_timestamp
FROM schema.source_table
WHERE is_active = 1;

Step 4: Export the data to the Lakehouse

There are two common ways: (A) copy directly with INSERT INTO ... SELECT pointing to the Lakehouse external table; (B) export to Parquet files and write to the Lakehouse path using utilities. Method A is straightforward and simple for one-off or simple recurring loads. For incremental loads, consider INSERT INTO by partition or using INSERT OVERWRITE on partitioned sets. For large volumes, it is recommended to test with batches of 100k–500k rows and verify the average Parquet file size (ideally 64–256 MB for a good balance between I/O and parallelism).

-- Método A: Inserir diretamente na tabela externa do Lakehouse
INSERT INTO lakehouse_schema.target_table
SELECT
  id,
  UPPER(name) AS name,
  CAST(amount AS DECIMAL(18,2)) AS amount,
  SYSUTCDATETIME() AS load_timestamp
FROM schema.source_table
WHERE is_active = 1;

Step 5: Validate write and manage permissions

After the insert, check that Parquet files were written to the Lakehouse path and adjust permissions if necessary. Ensure the identities (managed identity, service principal or user) have access to OneLake/Storage with the necessary permissions (Write/List). Validate integrity with counts: SELECT COUNT(*) on the source table vs the Lakehouse table and, if needed, samples with CHECKSUM of critical columns to detect losses or truncations. For production loads, log the identity used and create alerts for permission or quota errors.

-- Consulta de validação simples na tabela do Lakehouse
SELECT TOP 10 * FROM lakehouse_schema.target_table ORDER BY load_timestamp DESC;

Verify the result

Confirm that: (1) the number of rows in the target table matches the expectation (for example, 1,000,000 rows); (2) types and formats are correct (decimals, dates in UTC); (3) Parquet files appear in the Lakehouse directory with reasonable sizes; (4) applications like Power BI can read the table and respond to queries in an acceptable time. Run counts by partition and samples of critical values. A practical check: SELECT COUNT(*), MIN(load_timestamp), MAX(load_timestamp) to validate the time window.

Conclusion

You now have a simple, repeatable process to export data from a Warehouse to a Lakehouse in Microsoft Fabric while preserving schema and applying light transformations. Next steps: automate with Pipelines in Fabric Data Factory, create snapshots with Time Travel or implement incremental loads with watermarking. Practical tip: always log the identity used for writes, set batch limits for large loads and check quotas before massive loads to avoid interruptions.