Databricks Migration

Update Check — ONCE PER SESSION (mandatory)

The first time this skill is used in a session, run the check-updates skill before proceeding.

- GitHub Copilot CLI / VS Code: invoke the check-updates skill.

- Claude Code / Cowork / Cursor / Windsurf / Codex: compare local vs remote package.json version.

- Skip if the check was already performed earlier in this session.

CRITICAL NOTES

1. To find workspace details (including its ID) from a workspace name: list all workspaces, then use JMESPath filtering

2. To find item details (including its ID) from workspace ID, item type, and item name: list all items of that type in that workspace, then use JMESPath filtering

3. dbutils.widgets has no direct equivalent in Fabric — use notebook parameters (cell tag parameters) or notebookutils.runtime.context for context injection

4. dbutils.library (runtime library install) has no equivalent — use Fabric Environments for reproducible library management

5. Unity Catalog uses a 3-level namespace (catalog.schema.table); Fabric Lakehouse uses 2-level (schema.table within a named Lakehouse)

Databricks → Microsoft Fabric Migration

Prerequisite Knowledge

Read these companion documents before executing migration tasks:

• COMMON-CORE.md — Fabric REST API patterns, authentication, token audiences, item discovery
• COMMON-CLI.md — az rest, az login, token acquisition, Fabric REST via CLI
• SPARK-AUTHORING-CORE.md — Notebook deployment, lakehouse creation, Spark job execution

For notebook and Lakehouse creation, see spark-authoring-cli. For Fabric Warehouse DDL/DML authoring, see sqldw-authoring-cli.

---

Table of Contents

---

Migration Workload Map

---

dbutils → notebookutils Quick Reference

The complete side-by-side API table is in dbutils-to-notebookutils.md. The key mappings are:

Widgets Migration

dbutils.widgets has no direct equivalent in Fabric. Use these patterns instead:

Note: notebookutils.runtime.context does not expose parameter values. It's for execution metadata (workspace/notebook/activity/user IDs, pipeline-vs-interactive flags, etc.). See dbutils-to-notebookutils.md § Runtime Context.

---

Cluster Config → Fabric Spark Pools

---

Databricks Jobs → Spark Job Definitions

Delegate to `spark-authoring-cli` for SJD creation and notebook deployment.

---

Delta Sharing → OneLake Shortcuts

---

MLflow → Fabric ML Experiments

Fabric ML Experiments are built on the MLflow SDK — most code is directly portable:

---

Must / Prefer / Avoid

MUST DO

• *Replace all `dbutils. calls** using the mapping in [dbutils-to-notebookutils.md](resources/dbutils-to-notebookutils.md) — dbutils` is not available in Fabric notebooks
• Migrate `dbutils.fs.mount()` to `notebookutils.fs.mount()` (✅ supported — Microsoft Entra default, or accountKey / sasToken from Key Vault). For cross-workspace or persistent sharing, prefer OneLake Shortcuts instead. Always pair mount() with unmount() in try/finally — Fabric mounts are not released automatically on session end
• Replace `dbutils.secrets.get(scope, key)` with notebookutils.credentials.getSecret(keyVaultUrl, secretName) — secret scopes map to Azure Key Vault URLs
• Redesign widget-based parameter passing using notebook parameters cells (cell "..." menu → "Mark cell as parameters"); use notebookutils.variableLibrary for centralized cross-notebook config. notebookutils.runtime.context does not expose parameter values
• *Replace `dbutils.library.install()** with Fabric **Environments** — runtime library installs are not supported in production. dbutils.library.restartPython() maps to notebookutils.session.restartPython()` (Python / PySpark only)
• Adapt Unity Catalog 3-level namespaces (catalog.schema.table) to Fabric 2-level (schema.table within a Lakehouse) — see catalog-migration.md
• Map Databricks cluster init scripts to Fabric Environments — cluster-level library installs must move to Environment items

PREFER

• Fabric Native Execution Engine (NEE) as the Photon equivalent — enable in workspace Spark settings for vectorized execution on Delta Lake
• OneLake Shortcuts over data copy for Delta tables that already exist in ADLS Gen2 — point directly without re-ingesting
• Fabric Git Integration as the replacement for Databricks Repos — connect workspace to ADO or GitHub for notebook version control
• Fabric ML Experiments for direct MLflow continuity — tracking code requires minimal changes (remove set_tracking_uri)
• Medallion architecture when restructuring migrated Databricks catalogs — align bronze, silver, gold Unity Catalog schemas to separate Fabric Lakehouses
• Starter Pool for migrating interactive notebook workflows — eliminates cluster startup time that was a common pain point in Databricks job clusters

AVOID

• Do not import `dbutils` or attempt `dbutils = ...` assignments in Fabric notebooks — this will raise NameError; always use notebookutils
• Do not assume Unity Catalog governance policies transfer automatically — RBAC, row-level security, and column masking must be reconfigured in Fabric using workspace roles and Lakehouse permissions
• Do not use `%pip install` in production Fabric notebooks at runtime — use Fabric Environments for stable, versioned library management
• Do not attempt to port Delta Live Tables (DLT) pipelines verbatim — DLT has no Fabric equivalent; rewrite as parameterized notebooks orchestrated by Fabric Pipelines
• Do not rely on Databricks-specific Spark configurations (e.g., spark.databricks.*) — these are proprietary and will be silently ignored or raise errors in Fabric
• Do not use DBFS paths (dbfs:/...) — there is no DBFS in Fabric; all paths must use OneLake abfss:// or Lakehouse-relative paths

---

Examples

See dbutils-to-notebookutils.md and code-patterns.md for the full mapping. Key quick references:

`dbutils.fs` → `notebookutils.fs`

# Databricks
dbutils.fs.ls("/mnt/bronze/orders/")
dbutils.fs.cp("/mnt/raw/file.csv", "/mnt/archive/file.csv")

# Fabric (replace DBFS/mount paths with OneLake relative paths)
notebookutils.fs.ls("Files/bronze/orders/")
notebookutils.fs.cp("Files/raw/file.csv", "Files/archive/file.csv")

`dbutils.secrets` → `notebookutils.credentials`

# Databricks
pwd = dbutils.secrets.get(scope="prod", key="db-password")

# Fabric (scope → Key Vault URL, key → secret name)
pwd = notebookutils.credentials.getSecret("https://myvault.vault.azure.net/", "db-password")

Unity Catalog namespace → Lakehouse schema

# Databricks
df = spark.read.table("prod.silver.customers")

# Fabric (catalog dropped; Lakehouse context provides it)
df = spark.read.table("silver.customers")

Unity Catalog → Fabric Lakehouse Schema Migration

Reference for migrating Databricks Unity Catalog namespace structures to Microsoft Fabric Lakehouse schemas.

---

Namespace Model Comparison

---

Mapping Strategy

Option A: One Lakehouse per Unity Catalog

Best for: organizations with distinct catalogs for dev, test, prod, or bronze/silver/gold.

Option B: One Lakehouse per Schema (for large orgs)

Best for: organizations where schemas represent independent domains with separate ownership.

Option C: Medallion-aligned Lakehouses

Best for: migrating Bronze/Silver/Gold Unity Catalog pattern.

---

DDL Migration

Create Schema (identical syntax)

-- Databricks
CREATE SCHEMA IF NOT EXISTS prod.finance
    COMMENT 'Finance domain tables'
    MANAGED LOCATION 'abfss://...';

-- Fabric Spark SQL (attach to target Lakehouse first)
CREATE SCHEMA IF NOT EXISTS finance
    COMMENT 'Finance domain tables';
-- Note: MANAGED LOCATION is controlled by the Lakehouse; remove the clause

Create Table

-- BEFORE — Databricks Unity Catalog
CREATE TABLE IF NOT EXISTS prod.finance.fact_transactions (
    txn_id      BIGINT NOT NULL,
    account_id  INT,
    txn_date    DATE,
    amount      DECIMAL(18,4),
    currency    STRING
)
USING DELTA
COMMENT 'Daily financial transactions'
PARTITIONED BY (txn_date)
TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true');

-- AFTER — Fabric (catalog removed; same Lakehouse assumed)
CREATE TABLE IF NOT EXISTS finance.fact_transactions (
    txn_id      BIGINT NOT NULL,
    account_id  INT,
    txn_date    DATE,
    amount      DECIMAL(18,4),
    currency    STRING
)
USING DELTA
COMMENT 'Daily financial transactions'
PARTITIONED BY (txn_date)
TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true');
-- Note: TBLPROPERTIES are supported; Delta properties transfer as-is

Cross-Catalog Table Reference

# BEFORE — Databricks: read from another catalog
df = spark.sql("SELECT * FROM prod.silver.customers c JOIN staging.bronze.raw_events e ON c.id = e.customer_id")

# AFTER — Fabric Option A: use Spark SQL with schema-qualified names (within attached Lakehouse)
df = spark.sql("SELECT * FROM silver.customers c JOIN bronze.raw_events e ON c.id = e.customer_id")

# AFTER — Fabric Option B: create a OneLake Shortcut to the other Lakehouse's table
# Then reference it as a local table in the current Lakehouse schema

---

Access Control Migration

Unity Catalog provides fine-grained RBAC, row filters, and column masks. Fabric provides workspace roles + Lakehouse permissions.

Governance gap: Unity Catalog offers more granular column-level masking than Fabric's current offering. Assess governance requirements before migration and plan for interim mitigations.

---

PySpark Code Changes

# BEFORE — Databricks: 3-level namespace in all reads/writes
df = spark.read.table("prod.silver.customers")
df.write.format("delta").mode("overwrite").saveAsTable("prod.gold.customer_summary")

# AFTER — Fabric: 2-level (catalog prefix removed)
df = spark.read.table("silver.customers")
df.write.format("delta").mode("overwrite").saveAsTable("gold.customer_summary")

# BEFORE — Databricks: set current catalog
spark.catalog.setCurrentCatalog("prod")
spark.catalog.setCurrentDatabase("finance")

# AFTER — Fabric: set current schema (catalog concept = active Lakehouse)
spark.sql("USE finance")
# To switch Lakehouse context, change the default Lakehouse attached to the notebook

---

Delta Table Properties

Most Delta table properties migrate without changes. Key properties to verify:

Databricks → Fabric Code Patterns

Before/after examples for common Databricks → Microsoft Fabric migration scenarios.

---

Notebook Header: dbutils → notebookutils

# BEFORE — Databricks: dbutils is built-in, no import needed
# But many notebooks have this pattern:
from pyspark.sql import SparkSession
spark = SparkSession.builder.getOrCreate()

# AFTER — Fabric: everything is pre-instantiated
# Remove: SparkSession.builder... (spark is already available)
# Remove: any dbutils.* references (replace per mapping below)
# notebookutils is available globally — no import needed

---

File System Operations

# BEFORE — Databricks: list files on DBFS mount
files = dbutils.fs.ls("/mnt/bronze/customers/")
for f in files:
    print(f.name, f.size)

# AFTER — Fabric
files = notebookutils.fs.ls("Files/customers/")  # relative to attached Lakehouse
for f in files:
    print(f.name, f.size)

# BEFORE — Databricks: copy file
dbutils.fs.cp("/mnt/raw/orders.csv", "/mnt/archive/orders.csv")

# AFTER — Fabric
notebookutils.fs.cp("Files/raw/orders.csv", "Files/archive/orders.csv")

# BEFORE — Databricks: write and read temp file
dbutils.fs.put("/tmp/checkpoint.txt", "batch_id=42", overwrite=True)
content = dbutils.fs.head("/tmp/checkpoint.txt")

# AFTER — Fabric
notebookutils.fs.put("Files/checkpoints/checkpoint.txt", "batch_id=42", overwrite=True)
content = notebookutils.fs.head("Files/checkpoints/checkpoint.txt")

---

Secret Retrieval

# BEFORE — Databricks
jdbc_password = dbutils.secrets.get(scope="prod-secrets", key="jdbc-password")
api_token     = dbutils.secrets.get(scope="prod-secrets", key="external-api-token")

spark.conf.set("spark.hadoop.fs.azure.account.key.myaccount.dfs.core.windows.net",
               dbutils.secrets.get("prod-secrets", "storage-key"))

# AFTER — Fabric
KV_URL = "https://prod-keyvault.vault.azure.net/"
jdbc_password = notebookutils.credentials.getSecret(KV_URL, "jdbc-password")
api_token     = notebookutils.credentials.getSecret(KV_URL, "external-api-token")

# For storage access: use OneLake shortcuts — no account key needed

---

DBFS Mount → OneLake Path

# BEFORE — Databricks: read from mounted ADLS
df = spark.read.format("delta").load("/mnt/silver/transactions/")
df = spark.read.parquet("/mnt/raw/events/2024/01/")

# AFTER — Fabric: read from Lakehouse (after creating OneLake shortcut)
df = spark.read.format("delta").load("Tables/transactions")         # Delta table
df = spark.read.parquet("Files/events/2024/01/")                   # raw files

---

Notebook Orchestration

# BEFORE — Databricks
result = dbutils.notebook.run(
    "/Shared/ETL/silver_transform",
    timeout=600,
    arguments={"date": "2024-01-01", "env": "prod"}
)
status = result  # notebook's exit value

dbutils.notebook.exit("transform_complete")

# AFTER — Fabric (identical structure; name replaces path)
result = notebookutils.notebook.run(
    "silver_transform",
    timeout=600,
    arguments={"date": "2024-01-01", "env": "prod"}
)
status = result

notebookutils.notebook.exit("transform_complete")

---

Widget Parameters → Notebook Parameters

# BEFORE — Databricks
dbutils.widgets.text("batch_date", "2024-01-01")
dbutils.widgets.dropdown("environment", "dev", ["dev", "test", "prod"])
batch_date = dbutils.widgets.get("batch_date")
environment = dbutils.widgets.get("environment")

# AFTER — Fabric: use a "parameters" tagged cell
# Tag the cell below as "parameters" in the notebook UI
batch_date = "2024-01-01"   # overridden by pipeline or parent notebook at runtime
environment = "dev"

# Read pipeline-injected values programmatically (if needed):
ctx = notebookutils.runtime.context
params = ctx.get("parameters", {})
batch_date = params.get("batch_date", "2024-01-01")
environment = params.get("environment", "dev")

---

Unity Catalog Reads → Lakehouse Schema Reads

# BEFORE — Databricks: 3-level namespace
customers = spark.read.table("prod.silver.customers")
orders    = spark.read.table("prod.silver.orders")
result    = customers.join(orders, "customer_id")
result.write.format("delta").mode("overwrite").saveAsTable("prod.gold.customer_orders")

# AFTER — Fabric: 2-level (catalog removed; Lakehouse context provides catalog)
customers = spark.read.table("silver.customers")
orders    = spark.read.table("silver.orders")
result    = customers.join(orders, "customer_id")
result.write.format("delta").mode("overwrite").saveAsTable("gold.customer_orders")

---

Delta MERGE (identical — no changes needed)

# Databricks Delta MERGE — works identically in Fabric
from delta.tables import DeltaTable

target = DeltaTable.forName(spark, "silver.customers")
target.alias("t").merge(
    updates.alias("s"),
    "t.customer_id = s.customer_id"
).whenMatchedUpdate(set={
    "email": "s.email",
    "updated_at": "s.updated_at"
}).whenNotMatchedInsertAll() \
 .execute()

---

MLflow Tracking

# BEFORE — Databricks: set tracking URI to Databricks
import mlflow
mlflow.set_tracking_uri("databricks")
mlflow.set_experiment("/Users/user@company.com/MyExperiment")

with mlflow.start_run():
    mlflow.log_param("learning_rate", 0.01)
    mlflow.log_metric("accuracy", 0.95)
    mlflow.sklearn.log_model(model, "model")

# AFTER — Fabric: remove set_tracking_uri; use experiment name only
import mlflow
mlflow.set_experiment("MyExperiment")  # Fabric creates the Experiment item automatically

with mlflow.start_run():
    mlflow.log_param("learning_rate", 0.01)
    mlflow.log_metric("accuracy", 0.95)
    mlflow.sklearn.log_model(model, "model")

---

Cluster-Level Library → Fabric Environment

# BEFORE — Databricks: runtime library install in notebook
dbutils.library.installPyPI("xgboost", version="1.7.0")
dbutils.library.restartPython()

import xgboost as xgb

# AFTER — Fabric:
# 1. Create or edit a Fabric Environment item
# 2. Add xgboost==1.7.0 to pip packages in the Environment
# 3. Attach the Environment to the notebook
# 4. Then in notebook — just import directly:
import xgboost as xgb
# No install code needed at runtime

---

Spark Configuration (Photon → NEE)

# BEFORE — Databricks: Photon is enabled at cluster level (no code change)
# Cluster config: "runtime_engine": "PHOTON"

# AFTER — Fabric: enable Native Execution Engine (similar vectorized execution)
# Enable in Fabric workspace Spark settings:
#   Spark compute → "Native Execution Engine" → On
# Or in notebook %%configure:
%%configure
{
    "conf": {
        "spark.microsoft.delta.nativeExecutionEngine.enabled": "true"
    }
}

dbutils → notebookutils Complete API Mapping

Exhaustive side-by-side reference for porting Databricks dbutils calls to Microsoft Fabric notebookutils.

---

Quick Compatibility Summary

---

dbutils.fs → notebookutils.fs

Most fs methods are direct replacements — only paths change (DBFS → OneLake/ABFSS). A few have minor signature differences (called out below).

Path Migration: DBFS → OneLake

# Databricks: DBFS path
dbutils.fs.ls("dbfs:/mnt/mydata/bronze/")
dbutils.fs.ls("/mnt/mydata/bronze/")         # shorthand

# Fabric: OneLake path (Files section of attached Lakehouse)
notebookutils.fs.ls("Files/mydata/bronze/")  # relative path

# Or explicit OneLake path
notebookutils.fs.ls(
    "abfss://MyWorkspace@onelake.dfs.fabric.microsoft.com/BronzeLakehouse.Lakehouse/Files/mydata/bronze/"
)

Migrating dbutils.fs.mount()

Fabric supports two patterns for accessing remote storage. Pick the one that fits your scenario:

Option A — `notebookutils.fs.mount()` (direct equivalent of `dbutils.fs.mount()`)

Use this when you need a local file-system path (e.g. for libraries that don't speak ABFSS), when you're porting code that already relies on a mount, or for ad-hoc mounts inside a session.

# BEFORE — Databricks
dbutils.fs.mount(
    source="abfss://container@storageaccount.dfs.core.windows.net/",
    mount_point="/mnt/mydata",
    extra_configs={
        "fs.azure.account.oauth2.client.secret": dbutils.secrets.get("myScope", "clientSecret"),
        # ...other OAuth configs
    }
)

# AFTER — Fabric: Microsoft Entra (default, recommended) — no credentials in code
notebookutils.fs.mount(
    "abfss://container@storageaccount.dfs.core.windows.net",
    "/mydata"
)

try:
    # Access the mounted data:
    local_path = notebookutils.fs.getMountPath("/mydata")      # /synfs/notebook/{sessionId}/mydata
    with open(f"{local_path}/file.csv", "r") as f:
        data = f.read()
finally:
    # Mounts are NOT released automatically when the session ends — always unmount.
    notebookutils.fs.unmount("/mydata")

Alternative auth modes — pick one of these in place of the Entra mount() call above (don't mount the same point twice without an unmount() in between):

# Auth via account key from Key Vault
account_key = notebookutils.credentials.getSecret("https://my-kv.vault.azure.net/", "storageKey")
notebookutils.fs.mount(
    "abfss://container@storageaccount.dfs.core.windows.net",
    "/mydata",
    {"accountKey": account_key}
)

# Or auth via SAS token from Key Vault
sas_token = notebookutils.credentials.getSecret("https://my-kv.vault.azure.net/", "storageSas")
notebookutils.fs.mount(
    "abfss://container@storageaccount.dfs.core.windows.net",
    "/mydata",
    {"sasToken": sas_token}
)

Fabric mounts are job-level, not durable workspace-level shortcuts. Unmounting is not automatic when a session ends — mount points stay on the node until you call unmount() explicitly, so always pair mount() with unmount() (a try/finally block is the safe pattern).

Option B — OneLake Shortcuts (preferred for cross-workspace / persistent data sharing)

Use this when the same external location is consumed by many notebooks/pipelines, or when you want the storage to appear permanently inside a Lakehouse without per-session setup.

# Create a OneLake Shortcut once (Portal or REST API):
# https://learn.microsoft.com/fabric/onelake/onelake-shortcuts
# Then access directly — no runtime mounting required:
df = spark.read.parquet("Files/mydata/bronze/customers/")

---

dbutils.secrets → notebookutils.credentials

The concept maps directly — Databricks secret scopes correspond to Azure Key Vault instances.

notebookutils.credentials also exposes capabilities that have no dbutils.secrets equivalent:

# BEFORE — Databricks
password = dbutils.secrets.get(scope="prod-secrets", key="db-password")
api_key  = dbutils.secrets.get(scope="prod-secrets", key="api-key")

# AFTER — Fabric
password = notebookutils.credentials.getSecret(
    "https://my-keyvault.vault.azure.net/",
    "db-password"
)
api_key = notebookutils.credentials.getSecret(
    "https://my-keyvault.vault.azure.net/",
    "api-key"
)

The Fabric notebook's managed identity (or the signed-in user) must have Key Vault Secrets User role on the Key Vault.

---

dbutils.notebook → notebookutils.notebook

notebookutils.notebook is a superset of dbutils.notebook. run/exit are direct replacements, and it also adds DAG-based parallel execution, cross-workspace runs, and CRUD operations on notebook artifacts.

notebookutils.notebook also adds:

# BEFORE — Databricks
result = dbutils.notebook.run(
    "/path/to/silver_transform",
    timeout=600,
    arguments={"input_date": "2024-01-01", "env": "prod"}
)
dbutils.notebook.exit("completed")

# AFTER — Fabric: single notebook
result = notebookutils.notebook.run(
    "silver_transform",          # notebook name in the same workspace
    600,
    {"input_date": "2024-01-01", "env": "prod"}
)

# AFTER — Fabric: cross-workspace (pass the workspace ID)
result = notebookutils.notebook.run(
    "silver_transform",
    600,
    {"input_date": "2024-01-01"},
    "fe0a6e2a-a909-4aa3-a698-0a651de790aa"   # workspace ID (single run() requires ID)
)

notebookutils.notebook.exit("completed")

# AFTER — Fabric: parallel DAG (replaces Databricks Threads/Futures patterns)
DAG = {
    "activities": [
        {"name": "Extract",   "path": "bronze_ingest", "args": {"date": "2024-01-01"}},
        {"name": "Transform", "path": "silver_transform",
         "args": {"in": "@activity('Extract').exitValue()"},
         "dependencies": ["Extract"], "retry": 2, "retryIntervalInSeconds": 30},
    ],
    "concurrency": 4,
    "timeoutInSeconds": 3600,
}
notebookutils.notebook.validateDAG(DAG)
results = notebookutils.notebook.runMultiple(DAG)

---

dbutils.widgets — No Direct Equivalent

Databricks widgets are interactive UI controls. Fabric uses parameter cells (mark a cell as "parameters" in the UI — values are overridden at runtime), with notebookutils.variableLibrary for centralized configuration.

Pattern 1: Parameter cell (most common — works for both pipeline injection and parent→child runs)

# BEFORE — Databricks: define widget, read in notebook
dbutils.widgets.text("input_date", "2024-01-01", "Input Date")
input_date = dbutils.widgets.get("input_date")

# AFTER — Fabric: mark a cell as a parameters cell. In the notebook UI, open the cell's
# More commands ("...") and select "Mark cell as parameters" (older UI: "Toggle parameter cell").
# Declare defaults — at runtime, the engine adds a NEW cell beneath the parameters cell that
# overrides these values. Override sources:
#   - Fabric Pipeline notebook activity (Base parameters)
#   - notebookutils.notebook.run(..., arguments={...}) from a parent notebook
input_date = "2024-01-01"
env = "dev"

Pattern 2: Centralized config via Variable Library

# AFTER — Fabric: pull environment-specific values from a Variable Library
# (deployment pipelines activate the right value set per stage)
cfg = notebookutils.variableLibrary.getLibrary("app_config")
input_date = cfg.input_date
api_endpoint = cfg.api_endpoint

⚠️ Caveats (per docs): notebookutils.variableLibrary is same-workspace only — cross-workspace reads (including child notebooks in a cross-workspace reference run) are not supported. Service Principal (SPN) identity is not supported for variable library calls, so this pattern can't drive centralized config in SPN-authenticated CI/CD pipelines today.

Pattern 3: Parent notebook passes parameters to child

# AFTER — Fabric: parent calls child with explicit args
result = notebookutils.notebook.run(
    "child_notebook",
    300,
    {"input_date": "2024-01-01", "table_name": "fact_orders"}
)
# In child_notebook, the parameter cell values are replaced with the passed args at runtime

---

dbutils.library → Fabric Environments + notebookutils.session

dbutils.library.install*() runtime install isn't available in Fabric — use Fabric Environments for reproducible library management. The interpreter restart helper, however, is available as notebookutils.session.restartPython().

# BEFORE — Databricks: runtime library install
dbutils.library.installPyPI("scikit-learn", version="1.3.0")
dbutils.library.install("dbfs:/mnt/libs/mylib-1.0.whl")
dbutils.library.restartPython()

# AFTER — Fabric option A (preferred): Fabric Environment
# 1. Create a Fabric Environment item in the workspace.
# 2. Add `scikit-learn==1.3.0` to the Environment's pip packages.
# 3. For custom .whl files, upload as a custom library on the Environment item.
# 4. Attach the Environment to the notebook (or set as workspace default).
# No code change needed — the library is available on session start.

# AFTER — Fabric option B (ad-hoc, session-scoped): %pip + restartPython
# Cell 1: install and restart
%pip install scikit-learn==1.3.0
notebookutils.session.restartPython()

# Cell 2 (a NEW cell — code after restartPython() in the same cell does NOT run):
import sklearn

Also available: stop the interactive session

notebookutils.session.stop()        # async; releases Spark resources to the pool
# PySpark/Scala/R: stop() accepts an optional `detach` parameter (Python notebook doesn't).
#   - Default behavior (detach=True): on a high-concurrency session, detaches the session
#     instead of stopping it entirely.
#   - stop(detach=False): fully stops a high-concurrency session.

---

dbutils.data — Use display() or pandas

# BEFORE — Databricks: summarize a DataFrame
dbutils.data.summarize(df)

# AFTER — Fabric: use built-in display or pandas
display(df.summary())           # Spark summary stats in Fabric display
display(df.describe())          # Alternative
df.toPandas().describe()        # Full pandas stats (for small DataFrames only)

---

Runtime Context

notebookutils.runtime.context returns a read-only map. Property names use the current* / default* / root* prefix — they are not the same names as Databricks tags. The sample below shows the most common keys; the full key list (including defaultLakehouseWorkspaceId, currentRunId/parentRunId/rootRunId, rootNotebookName, clusterId, poolName, environmentWorkspaceId, currentKernel, productType, hcReplId, etc.) is on the runtime context docs page.

# BEFORE — Databricks: access job context
ctx = dbutils.notebook.entry_point.getDbutils().notebook().getContext()
workspace = ctx.tags().get("orgId").get()
job_id    = ctx.tags().get("jobId").get()

# AFTER — Fabric
ctx = notebookutils.runtime.context

workspace_id        = ctx["currentWorkspaceId"]
workspace_name      = ctx["currentWorkspaceName"]
notebook_id         = ctx["currentNotebookId"]
notebook_name       = ctx["currentNotebookName"]

# Default lakehouse (only populated when one is attached)
lakehouse_id        = ctx.get("defaultLakehouseId")
lakehouse_name      = ctx.get("defaultLakehouseName")

# Execution mode flags — useful for pipeline-vs-interactive branching
is_pipeline         = ctx["isForPipeline"]
is_interactive      = ctx["isForInteractive"]
is_reference_run    = ctx["isReferenceRun"]

# Job / activity identity
activity_id         = ctx["activityId"]        # Livy job ID for current activity (closest to Databricks jobId)
environment_id      = ctx.get("environmentId")
user_id             = ctx["userId"]
user_name           = ctx["userName"]

The runtime context does not expose pipeline parameters under a parameters key — parameter values arrive via parameter-cell overrides (see the dbutils.widgets section).