diff --git a/src/config/sidebar.ts b/src/config/sidebar.ts
index 9a8c7904100..71e709851bd 100644
--- a/src/config/sidebar.ts
+++ b/src/config/sidebar.ts
@@ -717,6 +717,11 @@ export const SIDEBAR: Partial<Record<Sections, SectionEntry[]>> = {
           url: "cre/reference/gelato-migration",
           highlightAsCurrent: ["cre/reference/gelato-migration-ts", "cre/reference/gelato-migration-go"],
         },
+        {
+          title: "Migrate from Chainlink Functions",
+          url: "cre/reference/clf-migration",
+          highlightAsCurrent: ["cre/reference/clf-migration-ts", "cre/reference/clf-migration-go"],
+        },
       ],
     },
   ],
diff --git a/src/content/chainlink-functions/getting-started.mdx b/src/content/chainlink-functions/getting-started.mdx
index 03997098f3e..b3f9af20181 100644
--- a/src/content/chainlink-functions/getting-started.mdx
+++ b/src/content/chainlink-functions/getting-started.mdx
@@ -13,11 +13,8 @@ whatsnext:
 
 import { Aside, CopyText, CodeSample, ClickToZoom } from "@components"
 import { Tabs } from "@components/Tabs"
-import ChainlinkFunctions from "@features/chainlink-functions/common/ChainlinkFunctions.astro"
 import { YouTube } from "@astro-community/astro-embed-youtube"
 
-<ChainlinkFunctions callout="cre" />
-
 Learn how to make requests to the Chainlink Functions Decentralized Oracle Network (DON) and make any computation or API calls offchain. Chainlink Functions is available on several blockchains (see the [supported networks page](/chainlink-functions/supported-networks)), but this guide uses Sepolia to simplify access to testnet funds. Complete the following tasks to get started with Chainlink Functions:
 
 - Set up your web3 wallet and fund it with testnet tokens.
diff --git a/src/content/chainlink-functions/index.mdx b/src/content/chainlink-functions/index.mdx
index 988a30af7b9..03c0934966d 100644
--- a/src/content/chainlink-functions/index.mdx
+++ b/src/content/chainlink-functions/index.mdx
@@ -12,9 +12,6 @@ whatsnext:
 ---
 
 import { Aside } from "@components"
-import ChainlinkFunctions from "@features/chainlink-functions/common/ChainlinkFunctions.astro"
-
-<ChainlinkFunctions callout="cre" />
 
 Chainlink Functions provides your smart contracts access to trust-minimized compute infrastructure, allowing you to fetch data from APIs and perform custom computation. Your smart contract sends source code in a request to a [Decentralized Oracle Network (DON)](/chainlink-functions/resources/concepts), and each node in the DON executes the code in a serverless environment. The DON then aggregates all the independent return values from each execution and sends the final result back to your smart contract.
 
diff --git a/src/content/chainlink-functions/llms-full.txt b/src/content/chainlink-functions/llms-full.txt
index 771ba03a57b..1fc2592bcdc 100644
--- a/src/content/chainlink-functions/llms-full.txt
+++ b/src/content/chainlink-functions/llms-full.txt
@@ -397,8 +397,6 @@ const myArr = new Uint8Array(ARRAY_LENGTH)
 # Getting Started
 Source: https://docs.chain.link/chainlink-functions/getting-started
 
-<ChainlinkFunctions callout="cre" />
-
 Learn how to make requests to the Chainlink Functions Decentralized Oracle Network (DON) and make any computation or API calls offchain. Chainlink Functions is available on several blockchains (see the [supported networks page](/chainlink-functions/supported-networks)), but this guide uses Sepolia to simplify access to testnet funds. Complete the following tasks to get started with Chainlink Functions:
 
 - Set up your web3 wallet and fund it with testnet tokens.
@@ -876,8 +874,6 @@ Now that you understand the structure of the API. Let's delve into the JavaScrip
 # Chainlink Functions
 Source: https://docs.chain.link/chainlink-functions
 
-<ChainlinkFunctions callout="cre" />
-
 Chainlink Functions provides your smart contracts access to trust-minimized compute infrastructure, allowing you to fetch data from APIs and perform custom computation. Your smart contract sends source code in a request to a [Decentralized Oracle Network (DON)](/chainlink-functions/resources/concepts), and each node in the DON executes the code in a serverless environment. The DON then aggregates all the independent return values from each execution and sends the final result back to your smart contract.
 
 Chainlink Functions eliminates the need for you to manage your own Chainlink node and provides decentralized offchain computation and consensus, ensuring that a minority of the network cannot manipulate the response sent back to your smart contract.
@@ -1223,12 +1219,6 @@ Source: https://docs.chain.link/chainlink-functions/resources
 # Secrets Management
 Source: https://docs.chain.link/chainlink-functions/resources/secrets
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 Chainlink Functions enables users to fetch data from HTTP(s) APIs and perform custom computation. To enable access to APIs that require authentication credentials, Chainlink Functions allows users to provide encrypted secret values, which can be used when the DON executes a Functions request. These values can only be decrypted via a multi-party decryption process called threshold decryption. This means that every node can only decrypt the secrets with participation from other DON nodes.
 
 These encrypted secret values can either be uploaded to the DON or hosted at a remote URL. Then, a reference to the encrypted secrets can be used when making a Functions request.
@@ -1372,23 +1362,11 @@ You can read the [Examine the code section](/chainlink-functions/tutorials/simpl
 
 **Note**: You can also import and use the Chainlink Functions Toolkit NPM package as a scripting dependency inside [Remix IDE scripts](https://remix-ide.readthedocs.io/en/latest/running_js_scripts.html) in your browser.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues. Please be aware that Chainlink
-  Functions does not control how your secrets or environment variables are used or accessed within Remix or when
-  executing scripts within Remix, and the safekeeping of secrets and environment variables is your responsibility.
-</Aside>
-
 ---
 
 # Managing CL Functions Subscriptions
 Source: https://docs.chain.link/chainlink-functions/resources/subscriptions
 
-<Aside type="note" title="Mainnet Beta">
-  Chainlink Functions is available on mainnet only as a BETA preview to ensure that this new platform is robust and secure for developers. While in BETA, developers must follow best practices and not use the BETA for any mission-critical application or secure any value. Chainlink Functions is likely to evolve and improve. Breaking changes might occur while the service is in BETA. Monitor these docs to stay updated on feature improvements along with interface and contract changes.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You are responsible for independently reviewing any code and API dependencies that you submit in a request. Community-created code examples might not be audited, so you must independently review this code before you use it.
 
@@ -1516,12 +1494,6 @@ Developers who implement Chainlink Functions in their code and applications are
 
 ### Secrets
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 - **Self-hosted secrets**: Developers are responsible for securing self-hosted secrets, monitoring unauthorized access, auditing permissions, and ensuring that secrets are available for retrieval by Chainlink Functions when executing code.
 - **Secrets best practices**: For all types of secrets used with Chainlink Functions, developers must follow common best practices for managing secrets for applications. Developers are responsible for selecting, setting expiration time, monitoring, and rotating secrets to ensure the security of their applications and Chainlink Functions code.
 
@@ -2512,12 +2484,6 @@ To build a decentralized asset price, send a request to the DON to fetch the pri
 - [CoinGecko](https://www.coingecko.com/en/api/documentation)
 - [CoinPaprika](https://api.coinpaprika.com/)
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
@@ -3144,12 +3110,6 @@ Read the [Using Secrets in Requests](/chainlink-functions/tutorials/api-use-secr
 2. Encrypt the gist URL.
 3. Include the encrypted gist URL in your Chainlink Functions request.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
@@ -3333,12 +3293,6 @@ Read the [Using User-hosted (gist) Secrets in Requests](/chainlink-functions/tut
 4. Encrypt the S3 HTTPs URL .
 5. Include the encrypted URL in your Chainlink Functions request.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
@@ -3569,12 +3523,6 @@ This tutorial shows you how to send a request to a Decentralized Oracle Network
 
 The encrypted secrets are never stored onchain. This tutorial uses the threshold encryption feature. The encrypted secrets are stored with the DON. Read the [Secrets Management page](/chainlink-functions/resources/secrets) to learn more.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
@@ -3809,12 +3757,6 @@ Read the [Automate your Functions (Time-based Automation)](/chainlink-functions/
 
 After you deploy and set up your contract, Chainlink Automation triggers your function on every block.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
@@ -4092,12 +4034,6 @@ Read the [API multiple calls](/chainlink-functions/tutorials/api-multiple-calls)
 
   After you deploy and set up your contract, Chainlink Automation triggers your function according to a time schedule.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
@@ -4450,12 +4386,6 @@ Read the [Call Multiple Data Sources](/chainlink-functions/tutorials/api-multipl
 
 - Instead of sending the request data (source code, encrypted secrets reference, and arguments) in the request, you will first encode it offchain and then send the encoded request. Encoding the request offchain from your front end or a server rather than onchain from your smart contract. This helps save gas.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
diff --git a/src/content/chainlink-functions/resources/secrets.mdx b/src/content/chainlink-functions/resources/secrets.mdx
index 7fa85ddaa99..4519a23d19a 100644
--- a/src/content/chainlink-functions/resources/secrets.mdx
+++ b/src/content/chainlink-functions/resources/secrets.mdx
@@ -6,12 +6,6 @@ title: "Secrets Management"
 
 import { Aside } from "@components"
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 Chainlink Functions enables users to fetch data from HTTP(s) APIs and perform custom computation. To enable access to APIs that require authentication credentials, Chainlink Functions allows users to provide encrypted secret values, which can be used when the DON executes a Functions request. These values can only be decrypted via a multi-party decryption process called threshold decryption. This means that every node can only decrypt the secrets with participation from other DON nodes.
 
 These encrypted secret values can either be uploaded to the DON or hosted at a remote URL. Then, a reference to the encrypted secrets can be used when making a Functions request.
diff --git a/src/content/chainlink-functions/resources/simulation.mdx b/src/content/chainlink-functions/resources/simulation.mdx
index 695001bec03..c20d91ae0bd 100644
--- a/src/content/chainlink-functions/resources/simulation.mdx
+++ b/src/content/chainlink-functions/resources/simulation.mdx
@@ -78,11 +78,3 @@ Follow the [Simple Computation](/chainlink-functions/tutorials/simple-computatio
 You can read the [Examine the code section](/chainlink-functions/tutorials/simple-computation#javascript-example) for a detailed description of the code example.
 
 **Note**: You can also import and use the Chainlink Functions Toolkit NPM package as a scripting dependency inside [Remix IDE scripts](https://remix-ide.readthedocs.io/en/latest/running_js_scripts.html) in your browser.
-
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues. Please be aware that Chainlink
-  Functions does not control how your secrets or environment variables are used or accessed within Remix or when
-  executing scripts within Remix, and the safekeeping of secrets and environment variables is your responsibility.
-</Aside>
diff --git a/src/content/chainlink-functions/resources/subscriptions.mdx b/src/content/chainlink-functions/resources/subscriptions.mdx
index e3563d033a3..3ea2ffdf651 100644
--- a/src/content/chainlink-functions/resources/subscriptions.mdx
+++ b/src/content/chainlink-functions/resources/subscriptions.mdx
@@ -6,11 +6,6 @@ title: "Managing CL Functions Subscriptions"
 
 import { Aside, ClickToZoom } from "@components"
 
-<Aside type="note" title="Mainnet Beta">
-Chainlink Functions is available on mainnet only as a BETA preview to ensure that this new platform is robust and secure for developers. While in BETA, developers must follow best practices and not use the BETA for any mission-critical application or secure any value. Chainlink Functions is likely to evolve and improve. Breaking changes might occur while the service is in BETA. Monitor these docs to stay updated on feature improvements along with interface and contract changes.
-
-</Aside>
-
 <Aside type="note">
 Chainlink Functions is a self-service solution. You are responsible for independently reviewing any code and API dependencies that you submit in a request. Community-created code examples might not be audited, so you must independently review this code before you use it.
 
diff --git a/src/content/chainlink-functions/service-responsibility.mdx b/src/content/chainlink-functions/service-responsibility.mdx
index ff519864a34..a3390412d38 100644
--- a/src/content/chainlink-functions/service-responsibility.mdx
+++ b/src/content/chainlink-functions/service-responsibility.mdx
@@ -33,12 +33,6 @@ Developers who implement Chainlink Functions in their code and applications are
 
 ### Secrets
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 - **Self-hosted secrets**: Developers are responsible for securing self-hosted secrets, monitoring unauthorized access, auditing permissions, and ensuring that secrets are available for retrieval by Chainlink Functions when executing code.
 - **Secrets best practices**: For all types of secrets used with Chainlink Functions, developers must follow common best practices for managing secrets for applications. Developers are responsible for selecting, setting expiration time, monitoring, and rotating secrets to ensure the security of their applications and Chainlink Functions code.
 
diff --git a/src/content/chainlink-functions/tutorials/api-multiple-calls.mdx b/src/content/chainlink-functions/tutorials/api-multiple-calls.mdx
index 290bd0637b5..7c68fd5445f 100644
--- a/src/content/chainlink-functions/tutorials/api-multiple-calls.mdx
+++ b/src/content/chainlink-functions/tutorials/api-multiple-calls.mdx
@@ -16,12 +16,6 @@ To build a decentralized asset price, send a request to the DON to fetch the pri
 - [CoinGecko](https://www.coingecko.com/en/api/documentation)
 - [CoinPaprika](https://api.coinpaprika.com/)
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
diff --git a/src/content/chainlink-functions/tutorials/api-use-secrets-gist.mdx b/src/content/chainlink-functions/tutorials/api-use-secrets-gist.mdx
index 5b3b229a920..08677fe5b93 100644
--- a/src/content/chainlink-functions/tutorials/api-use-secrets-gist.mdx
+++ b/src/content/chainlink-functions/tutorials/api-use-secrets-gist.mdx
@@ -17,12 +17,6 @@ Read the [Using Secrets in Requests](/chainlink-functions/tutorials/api-use-secr
 1. Encrypt the gist URL.
 1. Include the encrypted gist URL in your Chainlink Functions request.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
diff --git a/src/content/chainlink-functions/tutorials/api-use-secrets-offchain.mdx b/src/content/chainlink-functions/tutorials/api-use-secrets-offchain.mdx
index 980a1af8e5e..f78866d4530 100644
--- a/src/content/chainlink-functions/tutorials/api-use-secrets-offchain.mdx
+++ b/src/content/chainlink-functions/tutorials/api-use-secrets-offchain.mdx
@@ -19,12 +19,6 @@ Read the [Using User-hosted (gist) Secrets in Requests](/chainlink-functions/tut
 1. Encrypt the S3 HTTPs URL .
 1. Include the encrypted URL in your Chainlink Functions request.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
diff --git a/src/content/chainlink-functions/tutorials/api-use-secrets.mdx b/src/content/chainlink-functions/tutorials/api-use-secrets.mdx
index 91ac86966f4..edfdf52ed54 100644
--- a/src/content/chainlink-functions/tutorials/api-use-secrets.mdx
+++ b/src/content/chainlink-functions/tutorials/api-use-secrets.mdx
@@ -11,12 +11,6 @@ This tutorial shows you how to send a request to a Decentralized Oracle Network
 
 The encrypted secrets are never stored onchain. This tutorial uses the threshold encryption feature. The encrypted secrets are stored with the DON. Read the [Secrets Management page](/chainlink-functions/resources/secrets) to learn more.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
diff --git a/src/content/chainlink-functions/tutorials/automate-functions-custom-logic.mdx b/src/content/chainlink-functions/tutorials/automate-functions-custom-logic.mdx
index aaa3b0fc5ce..ed205da5b8d 100644
--- a/src/content/chainlink-functions/tutorials/automate-functions-custom-logic.mdx
+++ b/src/content/chainlink-functions/tutorials/automate-functions-custom-logic.mdx
@@ -13,12 +13,6 @@ Read the [Automate your Functions (Time-based Automation)](/chainlink-functions/
 
 After you deploy and set up your contract, Chainlink Automation triggers your function on every block.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
diff --git a/src/content/chainlink-functions/tutorials/automate-functions.mdx b/src/content/chainlink-functions/tutorials/automate-functions.mdx
index 9369b79ed69..202fa477dba 100644
--- a/src/content/chainlink-functions/tutorials/automate-functions.mdx
+++ b/src/content/chainlink-functions/tutorials/automate-functions.mdx
@@ -15,12 +15,6 @@ Read the [API multiple calls](/chainlink-functions/tutorials/api-multiple-calls)
 
   After you deploy and set up your contract, Chainlink Automation triggers your function according to a time schedule.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
diff --git a/src/content/chainlink-functions/tutorials/encode-request-offchain.mdx b/src/content/chainlink-functions/tutorials/encode-request-offchain.mdx
index 2f32722a47d..b7c5801334b 100644
--- a/src/content/chainlink-functions/tutorials/encode-request-offchain.mdx
+++ b/src/content/chainlink-functions/tutorials/encode-request-offchain.mdx
@@ -20,12 +20,6 @@ Read the [Call Multiple Data Sources](/chainlink-functions/tutorials/api-multipl
 
 - Instead of sending the request data (source code, encrypted secrets reference, and arguments) in the request, you will first encode it offchain and then send the encoded request. Encoding the request offchain from your front end or a server rather than onchain from your smart contract. This helps save gas.
 
-<Aside type="caution">
-  Chainlink Functions is still in BETA. The use of secrets in your requests is an experimental feature that may not
-  operate as expected and is subject to change. Use of this feature is at your own risk and may result in unexpected
-  errors, possible revealing of the secret as new versions are released, or other issues.
-</Aside>
-
 <Aside type="note">
   Chainlink Functions is a self-service solution. You must ensure that the data sources or APIs specified in requests
   are of sufficient quality and have the proper availability for your use case. You are responsible for complying with
diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt
index f4b6f14ff89..90cc14258c5 100644
--- a/src/content/cre/llms-full-go.txt
+++ b/src/content/cre/llms-full-go.txt
@@ -16564,6 +16564,316 @@ Or explore the SDK reference for detailed API documentation:
 
 ---
 
+# Migrate from Chainlink Functions to Chainlink CRE
+Source: https://docs.chain.link/cre/reference/clf-migration-go
+Last Updated: 2026-05-11
+
+<Aside type="note" title="SDK Language: Go">
+  You're viewing the **Go** version of this guide. If you prefer TypeScript, use the language selector in the left
+  sidebar to switch to the TypeScript version.
+</Aside>
+
+This guide is for developers with production [Chainlink Functions (CLF)](/chainlink-functions) subscriptions migrating their requests to the [Chainlink Runtime Environment (CRE)](/cre) before mainnet shutdown on **August 12, 2026**.
+
+The majority of CLF use cases involve fetching off-chain data over HTTP and returning it to a consumer contract. That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer.
+
+## How CLF and CRE differ
+
+In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback.
+
+In CRE, the unit of execution is a [**workflow**](/cre/key-terms#workflow) - a Go (or TypeScript) project compiled to WebAssembly and registered with the network. Workflows are started by [**triggers**](/cre/key-terms#trigger) (cron schedule, HTTP request, or onchain log event), can perform multiple steps (HTTP fetches, onchain reads, onchain writes, calls to other [capabilities](/cre/key-terms#capability)) wrapped in your own business logic, and write data onchain through a signed-report flow that any contract implementing `IReceiver` can consume.
+
+Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an offchain relayer collapse into a single workflow.
+
+## Chain support
+
+CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported.
+
+For the canonical, up-to-date list of supported chains on CRE, see [Supported Networks](/cre/supported-networks-go).
+
+## Terminology
+
+| Chainlink Functions                                 | Chainlink CRE                                                              |
+| :-------------------------------------------------- | :------------------------------------------------------------------------- |
+| `FunctionsClient` consumer contract                 | `IReceiver` consumer contract (use `ReceiverTemplate`)                     |
+| `_sendRequest()` from a consumer                    | EVM Log trigger (replaces on-chain entry path)                             |
+| Inline JavaScript source (Deno sandbox)             | Go (or TypeScript) workflow compiled to WASM (not compatible with node.js) |
+| `Functions.makeHttpRequest()`                       | `http.SendRequest()`                                                       |
+| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver                             |
+| DON-hosted / remote-hosted secrets                  | Vault DON + `secrets.yaml` + `runtime.GetSecret()`                         |
+| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `cre-sdk-go`, `cre-cli`, `cre-templates`                                   |
+| Functions Playground UI                             | CRE CLI `cre workflow simulate`                                            |
+| Automation Time-based Upkeep → `sendRequest()`      | Built-in Cron trigger - no Automation upkeep needed                        |
+| `donId` + router address per chain                  | Chain selector + forwarder address per chain                               |
+
+## Configuration
+
+A CRE project is a standalone repository, not a string-encoded JavaScript source. The CLI (`cre`) scaffolds a project with the following files:
+
+- **`main.go`** - workflow code: trigger registration, handler logic, and capability calls.
+- **`config.<target>.json`** - non-secret runtime configuration (API URLs, contract addresses, chain selectors).
+- **`secrets.yaml`** - secret declarations; values are supplied via `.env` files locally and via the Vault DON in production.
+- **`workflow.yaml`** - workflow metadata: name, owner, secrets path, and target network.
+- **`project.yaml`** - project-level CRE settings.
+
+There is no equivalent in CLF, where the entire program is a string passed directly to `_sendRequest()`.
+
+## Triggers
+
+CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, offchain trigger, reaction to an event) requires gluing CLF together with Automation, an offchain cron, or a custom indexer. CRE makes the [trigger](/cre/guides/workflow/using-triggers/overview) first-class.
+
+### Time-based
+
+Replaces "[Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) calling `sendRequest()`." Use a [cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-go) directly.
+
+```go
+cronTrigger := cron.Trigger(&cron.Config{Schedule: "0 */5 * * * *"}) // every 5 min
+cre.Handler(cronTrigger, onCronTrigger)
+```
+
+Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix with `TZ=<timezone>` for timezone-aware scheduling.
+
+### Onchain events
+
+Directly replaces the on-chain entry path of `_sendRequest()`. Instead of your contract calling the DON, the DON watches for a specific event emitted by your contract (or any contract) and fires the handler with the decoded event data.
+
+```go
+logTrigger := evmClient.LogTrigger(&evm.LogTriggerConfig{
+    Addresses: [][]byte{ /* contract address bytes */ },
+    Topics:    [][]byte{ /* event signature hash bytes */ },
+})
+cre.Handler(logTrigger, onLog)
+```
+
+### HTTP triggers
+
+Replaces patterns where an off-chain application or webhook would send a Solidity transaction solely to trigger a Functions request. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key.
+
+```go
+httpTrigger := http.Trigger(&http.Config{
+    AuthorizedKeys: []*http.AuthorizedKey{
+        {Type: http.KeyType_EVM, Key: "0xYourAuthorizedSigner"},
+    },
+})
+cre.Handler(httpTrigger, onHTTPTrigger)
+```
+
+`AuthorizedKeys` is required for deployed workflows; an empty config is only valid in simulation.
+
+### Onchain events
+
+Replaces "offchain listener observes an event → Solidity transaction → calls `sendRequest()`." The [EVM Log trigger](/cre/guides/workflow/using-triggers/evm-log-trigger-go) watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event.
+
+```go
+logTrigger := evmClient.LogTrigger(&evm.LogTriggerConfig{
+    Addresses: [][]byte{ /* contract address bytes */ },
+    Topics:    [][]byte{ /* event signature hash bytes */ },
+})
+cre.Handler(logTrigger, onLog)
+```
+
+### Per-block triggers
+
+CRE does not offer a "fire on every block" trigger; for high-frequency onchain reactions, use the EVM Log trigger with a [`LATEST` confidence level](/cre/concepts/finality-go). For periodic state polling, use a cron trigger and call `evmClient.CallContract()` from the handler.
+
+## Task authoring and output
+
+<Aside type="caution" title="Determinism requirement">
+  CRE workflows run on multiple nodes that must reach consensus on a single result. Any code that produces different
+  output per node — `time.Now()`, random number generation, non-deterministic map iteration, or reading mutable global
+  state — will cause the workflow to fail at the consensus step. Review the [Avoiding
+  Non-Determinism](/cre/concepts/non-determinism-go) guide before porting your CLF logic.
+</Aside>
+
+### Language and runtime
+
+CLF runs an inline JavaScript string in a per-request sandbox. Each request is independent; there is no project, no dependencies, and no compile step.
+
+CRE workflows are full Go or TypeScript projects compiled to WebAssembly. You manage dependencies with Go modules (for Go) and run `cre workflow simulate` for a local execution that mirrors production.
+
+<Aside type="caution" title="WASM Compatibility">
+  Because workflows compile to WASM, they are not compatible with environments that rely on native OS bindings or
+  non-WASM-compliant libraries. When migrating from CLF's JavaScript environment to Go, ensure your selected Go packages
+  are compatible with a WebAssembly target (e.g., they don't use `os`, `syscall`, or native CGO bindings).
+</Aside>
+
+The handler is single-threaded; SDK capability calls return an object that you resolve with `.Await()` (Go) or `.result()` (TypeScript).
+
+### HTTP / API calls
+
+Direct replacement for [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source). Supports GET and POST; consensus aggregation is automatic. See [API Interactions](/cre/guides/workflow/using-http-client) for full documentation.
+
+```go
+apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()
+if err != nil {
+    return err
+}
+
+res, err := http.SendRequest(runtime, &http.Request{
+    Url:    "https://api.example.com/price",
+    Method: "GET",
+    Headers: map[string]string{
+        "Authorization": "Bearer " + apiKey.Value,
+    },
+}).Await()
+```
+
+**Note:** 3xx redirects are not automatically followed; ensure you use the final resolved URL. For non-idempotent POSTs, set `CacheSettings` so the request is only executed once across the DON. Use `runtime.Now()` (not `time.Now()`) for any timestamps included in a request payload.
+
+### Onchain reads
+
+CLF has no built-in onchain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call.
+
+CRE workflows can read on-chain state directly from within the handler using built-in connectivity:
+
+```go
+evmClient := evm.NewClient(CHAIN_SELECTOR)
+result, err := evmClient.CallContract(runtime, &evm.CallContractRequest{
+    To:          CONTRACT_ADDRESS,
+    Data:        callData,
+    BlockNumber: evm.LastFinalizedBlockNumber,
+}).Await()
+```
+
+You can also still use HTTP requests to interact with your own RPCs.
+
+### Onchain writes
+
+The on-chain write process represents the most significant structural change when migrating from CLF. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`.
+
+This process involves two steps: ABI-encode the payload and call `runtime.GenerateReport()`, then submit the signed report with `evmClient.WriteReport()`.
+
+```go
+package main
+
+import (
+    "github.com/smartcontractkit/cre-sdk-go/cre"
+    "github.com/smartcontractkit/cre-sdk-go/capabilities/networking/http"
+    "github.com/smartcontractkit/cre-sdk-go/capabilities/blockchain/evm"
+    "github.com/smartcontractkit/cre-sdk-go/capabilities/scheduler/cron"
+)
+
+func onCronTrigger(runtime cre.Runtime, _ *cron.Payload) (any, error) {
+    apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()
+    if err != nil {
+        return nil, err
+    }
+
+    res, err := http.SendRequest(runtime, &http.Request{
+        Url: "https://api.example.com/price",
+        Headers: map[string]string{
+            "Authorization": "Bearer " + apiKey.Value,
+        },
+    }).Await()
+    if err != nil {
+        return nil, err
+    }
+
+    price := parsePrice(res.Body) // project-specific helper: parse and scale the response body
+    payload := encodePayload(price) // project-specific helper: ABI-encode the value
+
+    report, err := runtime.GenerateReport(&cre.ReportRequest{
+        EncodedPayload: payload,
+    }).Await()
+    if err != nil {
+        return nil, err
+    }
+
+    evmClient := evm.NewClient(CHAIN_SELECTOR)
+    _, err = evmClient.WriteReport(runtime, &evm.WriteReportRequest{
+        Receiver: RECEIVER_ADDRESS,
+        Report:   report,
+        GasConfig: &evm.GasConfig{GasLimit: 200000},
+    }).Await()
+    return nil, err
+}
+
+func InitWorkflow() (cre.Workflow, error) {
+    trigger := cron.Trigger(&cron.Config{Schedule: "*/5 * * * *"})
+    return cre.Workflow{
+        cre.Handler(trigger, onCronTrigger),
+    }, nil
+}
+```
+
+Receiver contract:
+
+```solidity
+import {ReceiverTemplate} from "@chainlink/cre-contracts/ReceiverTemplate.sol";
+
+contract PriceReceiver is ReceiverTemplate {
+  uint256 public price;
+
+  constructor(address forwarder) ReceiverTemplate(forwarder) {}
+
+  function _onReport(bytes calldata /* metadata */, bytes calldata payload) internal override {
+    price = abi.decode(payload, (uint256));
+  }
+}
+```
+
+Chain selectors and forwarder addresses are network-specific; see the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory-go) and [Supported Networks](/cre/supported-networks-go) for the values to substitute for `CHAIN_SELECTOR` and `RECEIVER_ADDRESS`. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) to learn how to permission your `IReceiver`.
+
+### Secrets
+
+CLF supports [DON-hosted secrets](/chainlink-functions/resources/secrets) (uploaded once via the Functions toolkit) and [user-hosted secrets](/chainlink-functions/tutorials/api-use-secrets-gist) (gist URL passed at request time). CRE [consolidates this through the Vault DON](/cre/guides/workflow/secrets).
+
+- **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var.
+- **Deployed:** upload to Vault DON via `cre secrets create`.
+- **In code:** `runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()` works the same in both environments.
+
+Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must register your secrets again using the `cre` CLI. See the [Project Configuration](/cre/reference/project-configuration-go#33-secrets-configuration-secretsyaml) documentation for detailed instructions on managing secrets with the Vault DON.
+
+## Monitoring
+
+The [CRE dashboard](/cre/guides/operations/monitoring-workflows) provides per-workflow execution history, handler logs (via `runtime.Logger()`), per-step timings, [consensus](/cre/concepts/consensus-computing) outcomes, and onchain submission status, replacing the per-request views in the [Functions Subscription Manager](/chainlink-functions/resources/subscriptions). Failed executions and reverted onchain writes surface directly in the workflow detail view.
+
+## Deployment and lifecycle
+
+| Action            | Chainlink Functions                                                                                             | Chainlink CRE                                                                                                                                                              |
+| :---------------- | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Author code       | Inline JS string in your consumer contract                                                                      | Go/TypeScript project; `cre workflow init` to scaffold                                                                                                                     |
+| Local test        | [Functions Playground](/chainlink-functions/resources/simulation) / `simulateScript`                            | [`cre workflow simulate`](/cre/guides/operations/simulating-workflows)                                                                                                     |
+| Deploy            | Deploy `FunctionsClient` consumer; [create and fund subscription](/chainlink-functions/resources/subscriptions) | Deploy `IReceiver` consumer; [`cre workflow deploy`](/cre/guides/operations/deploying-workflows); [activate workflow](/cre/guides/operations/activating-pausing-workflows) |
+| Update logic      | Re-deploy consumer (source baked into requests) or update gist                                                  | [`cre workflow update`](/cre/guides/operations/updating-deployed-workflows) (workflow code only; receiver unchanged)                                                       |
+| Pause             | Cancel subscription / set consumer flag                                                                         | [`cre workflow pause`](/cre/guides/operations/activating-pausing-workflows)                                                                                                |
+| Delete            | Remove consumer; withdraw remaining LINK from the subscription                                                  | [`cre workflow delete`](/cre/guides/operations/deleting-workflows)                                                                                                         |
+| Manage secrets    | [DON-hosted upload](/chainlink-functions/resources/secrets) via toolkit, expires after threshold                | [`cre secrets create / update / delete`](/cre/guides/workflow/secrets) against Vault DON                                                                                   |
+| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only                                                       | [Built-in email alerts on workflow failures; UI showing executions and DON logs](/cre/guides/operations/monitoring-workflows)                                              |
+
+## Get started
+
+To begin your migration, follow the [CRE Getting Started guide](/cre/getting-started/cli-installation) to install the CLI and initialize your first project.
+
+When mapping your existing CLF script:
+
+- Use `cre workflow init` to scaffold your project.
+- Replace your `_sendRequest()` logic with the appropriate [Triggers](#triggers) and [handler logic](#task-authoring-and-output).
+- Deploy a `ReceiverTemplate`-based consumer contract to receive reports.
+- Test your logic locally with `cre workflow simulate` before deploying with `cre workflow deploy`.
+
+Migrate your workflows one at a time and decommission your CLF subscriptions only after confirming the CRE workflows are successfully producing reports on-chain.
+
+For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo.
+
+### Reference template for CLF migration
+
+The closest one-to-one mapping for the typical CLF use case ("fetch offchain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both Go and TypeScript:
+
+- [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go)
+- [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts)
+
+It demonstrates each piece of the migration end-to-end:
+
+- A [**cron trigger**](/cre/guides/workflow/using-triggers/cron-trigger-go) scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a [**log trigger**](/cre/guides/workflow/using-triggers/evm-log-trigger-go) variant (replaces an offchain listener reacting to an onchain event).
+- An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.GetSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets).
+- ABI-encoding the result, calling `runtime.GenerateReport()` to produce a signed report, and submitting it with `evmClient.WriteReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow).
+- A complete project layout — `main.go`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source.
+
+If your CLF script also reads onchain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.CallContract()` replacement covered in the [Onchain reads](#onchain-reads) section above.
+
+---
+
 # Project Setup Commands
 Source: https://docs.chain.link/cre/reference/cli/project-setup-go
 Last Updated: 2026-03-26
diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt
index 00623c145ed..eb161e22acb 100644
--- a/src/content/cre/llms-full-ts.txt
+++ b/src/content/cre/llms-full-ts.txt
@@ -16491,6 +16491,286 @@ Or explore the SDK reference for detailed API documentation:
 
 ---
 
+# Migrate from Chainlink Functions to Chainlink CRE
+Source: https://docs.chain.link/cre/reference/clf-migration-ts
+Last Updated: 2026-05-11
+
+<Aside type="note" title="SDK Language: TypeScript">
+  You're viewing the **TypeScript** version of this guide. If you prefer Go, use the language selector in the left
+  sidebar to switch to the Go version.
+</Aside>
+
+This guide is for developers with production [Chainlink Functions (CLF)](/chainlink-functions) subscriptions migrating their requests to the [Chainlink Runtime Environment (CRE)](/cre) before mainnet shutdown on **August 12, 2026**.
+
+The majority of CLF use cases involve fetching off-chain data over HTTP and returning it to a consumer contract. That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer.
+
+## How CLF and CRE differ
+
+In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback.
+
+In CRE, the unit of execution is a [**workflow**](/cre/key-terms#workflow) - a TypeScript (or Go) project compiled to WebAssembly and registered with the network. Workflows are started by [**triggers**](/cre/key-terms#trigger) (cron schedule, HTTP request, or onchain log event), can perform multiple steps (HTTP fetches, onchain reads, onchain writes, calls to other [capabilities](/cre/key-terms#capability)) wrapped in your own business logic, and write data onchain through a signed-report flow that any contract implementing `IReceiver` can consume.
+
+Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an offchain relayer collapse into a single workflow.
+
+## Chain support
+
+CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported.
+
+For the canonical, up-to-date list of supported chains, see [Supported Networks](/cre/supported-networks-ts).
+
+## Terminology
+
+| Chainlink Functions                                 | Chainlink CRE                                                              |
+| :-------------------------------------------------- | :------------------------------------------------------------------------- |
+| `FunctionsClient` consumer contract                 | `IReceiver` consumer contract (use `ReceiverTemplate`)                     |
+| `_sendRequest()` from a consumer                    | EVM Log trigger (replaces on-chain entry path)                             |
+| Inline JavaScript source (Deno sandbox)             | TypeScript (or Go) workflow compiled to WASM (not compatible with node.js) |
+| `Functions.makeHttpRequest()`                       | `runtime.http.sendRequest()`                                               |
+| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver                             |
+| DON-hosted / remote-hosted secrets                  | Vault DON + `secrets.yaml` + `runtime.getSecret()`                         |
+| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `@chainlink/cre-sdk`, `cre-cli`, `cre-templates`                           |
+| Functions Playground UI                             | CRE CLI `cre workflow simulate`                                            |
+| Automation Time-based Upkeep → `sendRequest()`      | Built-in Cron trigger - no Automation upkeep needed                        |
+| `donId` + router address per chain                  | Chain selector + forwarder address per chain                               |
+
+## Configuration
+
+A CRE project is a standalone repository, not a string-encoded JavaScript source. The CLI (`cre`) scaffolds a project with the following files:
+
+- **`main.ts`** - workflow code: trigger registration, handler logic, and capability calls.
+- **`config.json`** - non-secret runtime configuration (API URLs, contract addresses, chain selectors).
+- **`secrets.yaml`** - secret declarations; values are supplied via `.env` files locally and via the Vault DON in production.
+- **`workflow.yaml`** - workflow metadata: name, owner, secrets path, and target network.
+- **`project.yaml`** - project-level CRE settings.
+
+There is no equivalent in CLF, where the entire program is a string passed directly to `_sendRequest()`.
+
+## Triggers
+
+CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, offchain trigger, reaction to an event) requires gluing CLF together with Automation, an offchain cron, or a custom indexer. CRE makes the [trigger](/cre/guides/workflow/using-triggers/overview) first-class.
+
+### Time-based
+
+Replaces "[Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) calling `sendRequest()`." Use a [cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-ts) directly.
+
+```ts
+const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" }) // every 5 min
+```
+
+Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix with `TZ=<timezone>` for timezone-aware scheduling.
+
+### Onchain events
+
+Directly replaces the on-chain entry path of `_sendRequest()`. Instead of your contract calling the DON, the DON watches for a specific event emitted by your contract (or any contract) and fires the handler with the decoded event data.
+
+```ts
+const evmClient = new cre.evm.EVMClient(CHAIN_SELECTOR)
+const trigger = evmClient.logTrigger({
+  addresses: [
+    /* base64-encoded contract address */
+  ],
+  topics: [
+    /* base64-encoded event signature hash */
+  ],
+})
+```
+
+### HTTP triggers
+
+Replaces patterns where an off-chain application or webhook would send a Solidity transaction solely to trigger a Functions request. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key.
+
+```ts
+const trigger = cre.capabilities.http.trigger({
+  authorizedKeys: [{ type: "EVM", key: "0xYourAuthorizedSigner" }],
+})
+```
+
+`authorizedKeys` is required for deployed workflows; an empty config is only valid in simulation.
+
+### Per-block triggers
+
+CRE does not offer a "fire on every block" trigger; for high-frequency onchain reactions, use the EVM Log trigger with a [`LATEST` confidence level](/cre/concepts/finality-ts). For periodic state polling, use a cron trigger and call `evmClient.callContract()` from the handler.
+
+## Task authoring and output
+
+<Aside type="caution" title="Determinism requirement">
+  CRE workflows run on multiple nodes that must reach consensus on a single result. Any code that produces different
+  output per node — `Date.now()`, `Math.random()`, non-deterministic iteration, or reading mutable global state — will
+  cause the workflow to fail at the consensus step. Review the [Avoiding
+  Non-Determinism](/cre/concepts/non-determinism-ts) guide before porting your CLF logic.
+</Aside>
+
+### Language and runtime
+
+CLF runs an inline JavaScript string in a per-request sandbox. Each request is independent; there is no project, no dependencies, and no compile step.
+
+CRE workflows are full TypeScript or Go projects compiled to WebAssembly. You manage dependencies with your standard package manager (like `npm` or `pnpm`) and run `cre workflow simulate` for a local execution that mirrors production.
+
+<Aside type="caution" title="WASM Compatibility">
+  Because workflows compile to WASM, they are not compatible with the Node.js runtime. Some common Node.js libraries
+  (like `fs`, `path`, or others that rely on native C++ bindings) will not work in a CRE environment. Ensure your
+  dependencies are WASM-compatible or browser-compatible.
+</Aside>
+
+The handler is single-threaded; SDK capability calls return an object that you resolve with `.result()` (TypeScript) or `.Await()` (Go).
+
+### HTTP / API calls
+
+Direct replacement for [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source). Supports GET and POST; consensus aggregation is automatic. See [API Interactions](/cre/guides/workflow/using-http-client) for full documentation.
+
+```ts
+const apiKey = await runtime.getSecret({ id: "API_KEY" }).result()
+
+const res = await runtime.http
+  .sendRequest({
+    url: "https://api.example.com/price",
+    method: "GET",
+    headers: { Authorization: `Bearer ${apiKey}` },
+  })
+  .result()
+
+const price = BigInt(Math.round(res.json().price * 100))
+```
+
+**Note:** 3xx redirects are not automatically followed; ensure you use the final resolved URL. For non-idempotent POSTs, set `cacheSettings` so the request is only executed once across the DON. Use `runtime.now()` (not `Date.now()`) for any timestamps included in a request payload.
+
+### Onchain reads
+
+CLF has no built-in onchain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call.
+
+CRE workflows can read on-chain state directly from within the handler using built-in connectivity:
+
+```ts
+const evm = new cre.evm.EVMClient(CHAIN_SELECTOR)
+const result = await evm
+  .callContract({
+    to: CONTRACT_ADDRESS,
+    data: encodeFunctionData({ abi, functionName: "latestAnswer" }),
+    blockNumber: cre.evm.LAST_FINALIZED_BLOCK_NUMBER,
+  })
+  .result()
+```
+
+You can also still use HTTP requests to interact with your own RPCs.
+
+### Onchain writes
+
+The on-chain write process represents the most significant structural change when migrating from CLF. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`.
+
+This process involves two steps: ABI-encode the payload and call `runtime.report()`, then submit the signed report with `evmClient.writeReport()`.
+
+```ts
+import { cre } from "@chainlink/cre-sdk"
+import { encodeAbiParameters } from "viem"
+
+export async function main() {
+  const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" })
+
+  cre.handler(trigger, async (runtime) => {
+    const apiKey = await runtime.getSecret({ id: "API_KEY" }).result()
+    const res = await runtime.http
+      .sendRequest({
+        url: "https://api.example.com/price",
+        headers: { Authorization: `Bearer ${apiKey}` },
+      })
+      .result()
+
+    const price = BigInt(Math.round(res.json().price * 100))
+    const payload = encodeAbiParameters([{ type: "uint256" }], [price])
+
+    const report = await runtime.report(payload).result()
+    const evm = new cre.evm.EVMClient(CHAIN_SELECTOR)
+    await evm
+      .writeReport({
+        receiver: RECEIVER_ADDRESS,
+        report,
+        gasLimit: "200000",
+      })
+      .result()
+  })
+
+  return cre.workflow()
+}
+```
+
+Receiver contract:
+
+```solidity
+import {ReceiverTemplate} from "@chainlink/cre-contracts/ReceiverTemplate.sol";
+
+contract PriceReceiver is ReceiverTemplate {
+  uint256 public price;
+
+  constructor(address forwarder) ReceiverTemplate(forwarder) {}
+
+  function _onReport(bytes calldata /* metadata */, bytes calldata payload) internal override {
+    price = abi.decode(payload, (uint256));
+  }
+}
+```
+
+Chain selectors and forwarder addresses are network-specific; see the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory-ts) and [Supported Networks](/cre/supported-networks-ts) for the values to substitute for `CHAIN_SELECTOR` and `RECEIVER_ADDRESS`. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) to learn how to permission your `IReceiver`.
+
+### Secrets
+
+CLF supports [DON-hosted secrets](/chainlink-functions/resources/secrets) (uploaded once via the Functions toolkit) and [user-hosted secrets](/chainlink-functions/tutorials/api-use-secrets-gist) (gist URL passed at request time). CRE [consolidates this through the Vault DON](/cre/guides/workflow/secrets).
+
+- **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var.
+- **Deployed:** upload to Vault DON via `cre secrets create`.
+- **In code:** `runtime.getSecret({ id: "API_KEY" }).result()` works the same in both environments.
+
+Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must register your secrets again using the `cre` CLI. See the [Project Configuration](/cre/reference/project-configuration-ts#33-secrets-configuration-secretsyaml) documentation for detailed instructions on managing secrets with the Vault DON.
+
+## Monitoring
+
+The [CRE dashboard](/cre/guides/operations/monitoring-workflows) provides per-workflow execution history, handler logs (via `runtime.log()`), per-step timings, [consensus](/cre/concepts/consensus-computing) outcomes, and onchain submission status, replacing the per-request views in the [Functions Subscription Manager](/chainlink-functions/resources/subscriptions). Failed executions and reverted onchain writes surface directly in the workflow detail view.
+
+## Deployment and lifecycle
+
+| Action            | Chainlink Functions                                                                                             | Chainlink CRE                                                                                                                                                              |
+| :---------------- | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Author code       | Inline JS string in your consumer contract                                                                      | TypeScript/Go project; `cre workflow init` to scaffold                                                                                                                     |
+| Local test        | [Functions Playground](/chainlink-functions/resources/simulation) / `simulateScript`                            | [`cre workflow simulate`](/cre/guides/operations/simulating-workflows)                                                                                                     |
+| Deploy            | Deploy `FunctionsClient` consumer; [create and fund subscription](/chainlink-functions/resources/subscriptions) | Deploy `IReceiver` consumer; [`cre workflow deploy`](/cre/guides/operations/deploying-workflows); [activate workflow](/cre/guides/operations/activating-pausing-workflows) |
+| Update logic      | Re-deploy consumer (source baked into requests) or update gist                                                  | [`cre workflow update`](/cre/guides/operations/updating-deployed-workflows) (workflow code only; receiver unchanged)                                                       |
+| Pause             | Cancel subscription / set consumer flag                                                                         | [`cre workflow pause`](/cre/guides/operations/activating-pausing-workflows)                                                                                                |
+| Delete            | Remove consumer; withdraw remaining LINK from the subscription                                                  | [`cre workflow delete`](/cre/guides/operations/deleting-workflows)                                                                                                         |
+| Manage secrets    | [DON-hosted upload](/chainlink-functions/resources/secrets) via toolkit, expires after threshold                | [`cre secrets create / update / delete`](/cre/guides/workflow/secrets) against Vault DON                                                                                   |
+| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only                                                       | [Built-in email alerts on workflow failures; UI showing executions and DON logs](/cre/guides/operations/monitoring-workflows)                                              |
+
+## Get started
+
+To begin your migration, follow the [CRE Getting Started guide](/cre/getting-started/cli-installation) to install the CLI and initialize your first project.
+
+When mapping your existing CLF script:
+
+- Use `cre workflow init` to scaffold your project.
+- Replace your `_sendRequest()` logic with the appropriate [Triggers](#triggers) and [handler logic](#task-authoring-and-output).
+- Deploy a `ReceiverTemplate`-based consumer contract to receive reports.
+- Test your logic locally with `cre workflow simulate` before deploying with `cre workflow deploy`.
+
+Migrate your workflows one at a time and decommission your CLF subscriptions only after confirming the CRE workflows are successfully producing reports on-chain.
+
+For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo.
+
+### Reference template for CLF migration
+
+The closest one-to-one mapping for the typical CLF use case ("fetch offchain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both TypeScript and Go:
+
+- [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts)
+- [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go)
+
+It demonstrates each piece of the migration end-to-end:
+
+- A [**cron trigger**](/cre/guides/workflow/using-triggers/cron-trigger-ts) scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a [**log trigger**](/cre/guides/workflow/using-triggers/evm-log-trigger-ts) variant (replaces an offchain listener reacting to an onchain event).
+- An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.getSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets).
+- ABI-encoding the result, calling `runtime.report()` to produce a signed report, and submitting it with `evmClient.writeReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow).
+- A complete project layout — `main.ts`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source.
+
+If your CLF script also reads onchain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.callContract()` replacement covered in the [Onchain reads](#onchain-reads) section above.
+
+---
+
 # Project Setup Commands
 Source: https://docs.chain.link/cre/reference/cli/project-setup-ts
 Last Updated: 2026-03-26
diff --git a/src/content/cre/reference/clf-migration-go.mdx b/src/content/cre/reference/clf-migration-go.mdx
new file mode 100644
index 00000000000..194a3a6eebb
--- /dev/null
+++ b/src/content/cre/reference/clf-migration-go.mdx
@@ -0,0 +1,317 @@
+---
+section: cre
+date: Last Modified
+title: "Migrate from Chainlink Functions to Chainlink CRE"
+pageId: "clf-migration"
+sdkLang: "go"
+metadata:
+  description: "Migrate from Chainlink Functions (CLF) to Chainlink CRE. Concept mapping, chain support, triggers, task authoring, secrets, onchain writes, deployment, and monitoring."
+  datePublished: "2026-05-11"
+  lastModified: "2026-05-11"
+---
+
+import { Aside } from "@components"
+
+<Aside type="note" title="SDK Language: Go">
+  You're viewing the **Go** version of this guide. If you prefer TypeScript, use the language selector in the left
+  sidebar to switch to the TypeScript version.
+</Aside>
+
+This guide is for developers with production [Chainlink Functions (CLF)](/chainlink-functions) subscriptions migrating their requests to the [Chainlink Runtime Environment (CRE)](/cre) before mainnet shutdown on **August 12, 2026**.
+
+The majority of CLF use cases involve fetching off-chain data over HTTP and returning it to a consumer contract. That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer.
+
+## How CLF and CRE differ
+
+In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback.
+
+In CRE, the unit of execution is a [**workflow**](/cre/key-terms#workflow) - a Go (or TypeScript) project compiled to WebAssembly and registered with the network. Workflows are started by [**triggers**](/cre/key-terms#trigger) (cron schedule, HTTP request, or onchain log event), can perform multiple steps (HTTP fetches, onchain reads, onchain writes, calls to other [capabilities](/cre/key-terms#capability)) wrapped in your own business logic, and write data onchain through a signed-report flow that any contract implementing `IReceiver` can consume.
+
+Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an offchain relayer collapse into a single workflow.
+
+## Chain support
+
+CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported.
+
+For the canonical, up-to-date list of supported chains on CRE, see [Supported Networks](/cre/supported-networks-go).
+
+## Terminology
+
+| Chainlink Functions                                 | Chainlink CRE                                                              |
+| :-------------------------------------------------- | :------------------------------------------------------------------------- |
+| `FunctionsClient` consumer contract                 | `IReceiver` consumer contract (use `ReceiverTemplate`)                     |
+| `_sendRequest()` from a consumer                    | EVM Log trigger (replaces on-chain entry path)                             |
+| Inline JavaScript source (Deno sandbox)             | Go (or TypeScript) workflow compiled to WASM (not compatible with node.js) |
+| `Functions.makeHttpRequest()`                       | `http.SendRequest()`                                                       |
+| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver                             |
+| DON-hosted / remote-hosted secrets                  | Vault DON + `secrets.yaml` + `runtime.GetSecret()`                         |
+| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `cre-sdk-go`, `cre-cli`, `cre-templates`                                   |
+| Functions Playground UI                             | CRE CLI `cre workflow simulate`                                            |
+| Automation Time-based Upkeep → `sendRequest()`      | Built-in Cron trigger - no Automation upkeep needed                        |
+| `donId` + router address per chain                  | Chain selector + forwarder address per chain                               |
+
+## Configuration
+
+A CRE project is a standalone repository, not a string-encoded JavaScript source. The CLI (`cre`) scaffolds a project with the following files:
+
+- **`main.go`** - workflow code: trigger registration, handler logic, and capability calls.
+- **`config.<target>.json`** - non-secret runtime configuration (API URLs, contract addresses, chain selectors).
+- **`secrets.yaml`** - secret declarations; values are supplied via `.env` files locally and via the Vault DON in production.
+- **`workflow.yaml`** - workflow metadata: name, owner, secrets path, and target network.
+- **`project.yaml`** - project-level CRE settings.
+
+There is no equivalent in CLF, where the entire program is a string passed directly to `_sendRequest()`.
+
+## Triggers
+
+CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, offchain trigger, reaction to an event) requires gluing CLF together with Automation, an offchain cron, or a custom indexer. CRE makes the [trigger](/cre/guides/workflow/using-triggers/overview) first-class.
+
+### Time-based
+
+Replaces "[Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) calling `sendRequest()`." Use a [cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-go) directly.
+
+```go
+cronTrigger := cron.Trigger(&cron.Config{Schedule: "0 */5 * * * *"}) // every 5 min
+cre.Handler(cronTrigger, onCronTrigger)
+```
+
+Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix with `TZ=<timezone>` for timezone-aware scheduling.
+
+### Onchain events
+
+Directly replaces the on-chain entry path of `_sendRequest()`. Instead of your contract calling the DON, the DON watches for a specific event emitted by your contract (or any contract) and fires the handler with the decoded event data.
+
+```go
+logTrigger := evmClient.LogTrigger(&evm.LogTriggerConfig{
+    Addresses: [][]byte{ /* contract address bytes */ },
+    Topics:    [][]byte{ /* event signature hash bytes */ },
+})
+cre.Handler(logTrigger, onLog)
+```
+
+### HTTP triggers
+
+Replaces patterns where an off-chain application or webhook would send a Solidity transaction solely to trigger a Functions request. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key.
+
+```go
+httpTrigger := http.Trigger(&http.Config{
+    AuthorizedKeys: []*http.AuthorizedKey{
+        {Type: http.KeyType_EVM, Key: "0xYourAuthorizedSigner"},
+    },
+})
+cre.Handler(httpTrigger, onHTTPTrigger)
+```
+
+`AuthorizedKeys` is required for deployed workflows; an empty config is only valid in simulation.
+
+### Onchain events
+
+Replaces "offchain listener observes an event → Solidity transaction → calls `sendRequest()`." The [EVM Log trigger](/cre/guides/workflow/using-triggers/evm-log-trigger-go) watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event.
+
+```go
+logTrigger := evmClient.LogTrigger(&evm.LogTriggerConfig{
+    Addresses: [][]byte{ /* contract address bytes */ },
+    Topics:    [][]byte{ /* event signature hash bytes */ },
+})
+cre.Handler(logTrigger, onLog)
+```
+
+### Per-block triggers
+
+CRE does not offer a "fire on every block" trigger; for high-frequency onchain reactions, use the EVM Log trigger with a [`LATEST` confidence level](/cre/concepts/finality-go). For periodic state polling, use a cron trigger and call `evmClient.CallContract()` from the handler.
+
+## Task authoring and output
+
+<Aside type="caution" title="Determinism requirement">
+  CRE workflows run on multiple nodes that must reach consensus on a single result. Any code that produces different
+  output per node — `time.Now()`, random number generation, non-deterministic map iteration, or reading mutable global
+  state — will cause the workflow to fail at the consensus step. Review the [Avoiding
+  Non-Determinism](/cre/concepts/non-determinism-go) guide before porting your CLF logic.
+</Aside>
+
+### Language and runtime
+
+CLF runs an inline JavaScript string in a per-request sandbox. Each request is independent; there is no project, no dependencies, and no compile step.
+
+CRE workflows are full Go or TypeScript projects compiled to WebAssembly. You manage dependencies with Go modules (for Go) and run `cre workflow simulate` for a local execution that mirrors production.
+
+<Aside type="caution" title="WASM Compatibility">
+  Because workflows compile to WASM, they are not compatible with environments that rely on native OS bindings or
+  non-WASM-compliant libraries. When migrating from CLF's JavaScript environment to Go, ensure your selected Go packages
+  are compatible with a WebAssembly target (e.g., they don't use `os`, `syscall`, or native CGO bindings).
+</Aside>
+
+The handler is single-threaded; SDK capability calls return an object that you resolve with `.Await()` (Go) or `.result()` (TypeScript).
+
+### HTTP / API calls
+
+Direct replacement for [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source). Supports GET and POST; consensus aggregation is automatic. See [API Interactions](/cre/guides/workflow/using-http-client) for full documentation.
+
+```go
+apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()
+if err != nil {
+    return err
+}
+
+res, err := http.SendRequest(runtime, &http.Request{
+    Url:    "https://api.example.com/price",
+    Method: "GET",
+    Headers: map[string]string{
+        "Authorization": "Bearer " + apiKey.Value,
+    },
+}).Await()
+```
+
+**Note:** 3xx redirects are not automatically followed; ensure you use the final resolved URL. For non-idempotent POSTs, set `CacheSettings` so the request is only executed once across the DON. Use `runtime.Now()` (not `time.Now()`) for any timestamps included in a request payload.
+
+### Onchain reads
+
+CLF has no built-in onchain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call.
+
+CRE workflows can read on-chain state directly from within the handler using built-in connectivity:
+
+```go
+evmClient := evm.NewClient(CHAIN_SELECTOR)
+result, err := evmClient.CallContract(runtime, &evm.CallContractRequest{
+    To:          CONTRACT_ADDRESS,
+    Data:        callData,
+    BlockNumber: evm.LastFinalizedBlockNumber,
+}).Await()
+```
+
+You can also still use HTTP requests to interact with your own RPCs.
+
+### Onchain writes
+
+The on-chain write process represents the most significant structural change when migrating from CLF. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`.
+
+This process involves two steps: ABI-encode the payload and call `runtime.GenerateReport()`, then submit the signed report with `evmClient.WriteReport()`.
+
+```go
+package main
+
+import (
+    "github.com/smartcontractkit/cre-sdk-go/cre"
+    "github.com/smartcontractkit/cre-sdk-go/capabilities/networking/http"
+    "github.com/smartcontractkit/cre-sdk-go/capabilities/blockchain/evm"
+    "github.com/smartcontractkit/cre-sdk-go/capabilities/scheduler/cron"
+)
+
+func onCronTrigger(runtime cre.Runtime, _ *cron.Payload) (any, error) {
+    apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()
+    if err != nil {
+        return nil, err
+    }
+
+    res, err := http.SendRequest(runtime, &http.Request{
+        Url: "https://api.example.com/price",
+        Headers: map[string]string{
+            "Authorization": "Bearer " + apiKey.Value,
+        },
+    }).Await()
+    if err != nil {
+        return nil, err
+    }
+
+    price := parsePrice(res.Body) // project-specific helper: parse and scale the response body
+    payload := encodePayload(price) // project-specific helper: ABI-encode the value
+
+    report, err := runtime.GenerateReport(&cre.ReportRequest{
+        EncodedPayload: payload,
+    }).Await()
+    if err != nil {
+        return nil, err
+    }
+
+    evmClient := evm.NewClient(CHAIN_SELECTOR)
+    _, err = evmClient.WriteReport(runtime, &evm.WriteReportRequest{
+        Receiver: RECEIVER_ADDRESS,
+        Report:   report,
+        GasConfig: &evm.GasConfig{GasLimit: 200000},
+    }).Await()
+    return nil, err
+}
+
+func InitWorkflow() (cre.Workflow, error) {
+    trigger := cron.Trigger(&cron.Config{Schedule: "*/5 * * * *"})
+    return cre.Workflow{
+        cre.Handler(trigger, onCronTrigger),
+    }, nil
+}
+```
+
+Receiver contract:
+
+```solidity
+import {ReceiverTemplate} from "@chainlink/cre-contracts/ReceiverTemplate.sol";
+
+contract PriceReceiver is ReceiverTemplate {
+  uint256 public price;
+
+  constructor(address forwarder) ReceiverTemplate(forwarder) {}
+
+  function _onReport(bytes calldata /* metadata */, bytes calldata payload) internal override {
+    price = abi.decode(payload, (uint256));
+  }
+}
+```
+
+Chain selectors and forwarder addresses are network-specific; see the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory-go) and [Supported Networks](/cre/supported-networks-go) for the values to substitute for `CHAIN_SELECTOR` and `RECEIVER_ADDRESS`. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) to learn how to permission your `IReceiver`.
+
+### Secrets
+
+CLF supports [DON-hosted secrets](/chainlink-functions/resources/secrets) (uploaded once via the Functions toolkit) and [user-hosted secrets](/chainlink-functions/tutorials/api-use-secrets-gist) (gist URL passed at request time). CRE [consolidates this through the Vault DON](/cre/guides/workflow/secrets).
+
+- **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var.
+- **Deployed:** upload to Vault DON via `cre secrets create`.
+- **In code:** `runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()` works the same in both environments.
+
+Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must register your secrets again using the `cre` CLI. See the [Project Configuration](/cre/reference/project-configuration-go#33-secrets-configuration-secretsyaml) documentation for detailed instructions on managing secrets with the Vault DON.
+
+## Monitoring
+
+The [CRE dashboard](/cre/guides/operations/monitoring-workflows) provides per-workflow execution history, handler logs (via `runtime.Logger()`), per-step timings, [consensus](/cre/concepts/consensus-computing) outcomes, and onchain submission status, replacing the per-request views in the [Functions Subscription Manager](/chainlink-functions/resources/subscriptions). Failed executions and reverted onchain writes surface directly in the workflow detail view.
+
+## Deployment and lifecycle
+
+| Action            | Chainlink Functions                                                                                             | Chainlink CRE                                                                                                                                                              |
+| :---------------- | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Author code       | Inline JS string in your consumer contract                                                                      | Go/TypeScript project; `cre workflow init` to scaffold                                                                                                                     |
+| Local test        | [Functions Playground](/chainlink-functions/resources/simulation) / `simulateScript`                            | [`cre workflow simulate`](/cre/guides/operations/simulating-workflows)                                                                                                     |
+| Deploy            | Deploy `FunctionsClient` consumer; [create and fund subscription](/chainlink-functions/resources/subscriptions) | Deploy `IReceiver` consumer; [`cre workflow deploy`](/cre/guides/operations/deploying-workflows); [activate workflow](/cre/guides/operations/activating-pausing-workflows) |
+| Update logic      | Re-deploy consumer (source baked into requests) or update gist                                                  | [`cre workflow update`](/cre/guides/operations/updating-deployed-workflows) (workflow code only; receiver unchanged)                                                       |
+| Pause             | Cancel subscription / set consumer flag                                                                         | [`cre workflow pause`](/cre/guides/operations/activating-pausing-workflows)                                                                                                |
+| Delete            | Remove consumer; withdraw remaining LINK from the subscription                                                  | [`cre workflow delete`](/cre/guides/operations/deleting-workflows)                                                                                                         |
+| Manage secrets    | [DON-hosted upload](/chainlink-functions/resources/secrets) via toolkit, expires after threshold                | [`cre secrets create / update / delete`](/cre/guides/workflow/secrets) against Vault DON                                                                                   |
+| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only                                                       | [Built-in email alerts on workflow failures; UI showing executions and DON logs](/cre/guides/operations/monitoring-workflows)                                              |
+
+## Get started
+
+To begin your migration, follow the [CRE Getting Started guide](/cre/getting-started/cli-installation) to install the CLI and initialize your first project.
+
+When mapping your existing CLF script:
+
+- Use `cre workflow init` to scaffold your project.
+- Replace your `_sendRequest()` logic with the appropriate [Triggers](#triggers) and [handler logic](#task-authoring-and-output).
+- Deploy a `ReceiverTemplate`-based consumer contract to receive reports.
+- Test your logic locally with `cre workflow simulate` before deploying with `cre workflow deploy`.
+
+Migrate your workflows one at a time and decommission your CLF subscriptions only after confirming the CRE workflows are successfully producing reports on-chain.
+
+For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo.
+
+### Reference template for CLF migration
+
+The closest one-to-one mapping for the typical CLF use case ("fetch offchain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both Go and TypeScript:
+
+- [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go)
+- [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts)
+
+It demonstrates each piece of the migration end-to-end:
+
+- A [**cron trigger**](/cre/guides/workflow/using-triggers/cron-trigger-go) scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a [**log trigger**](/cre/guides/workflow/using-triggers/evm-log-trigger-go) variant (replaces an offchain listener reacting to an onchain event).
+- An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.GetSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets).
+- ABI-encoding the result, calling `runtime.GenerateReport()` to produce a signed report, and submitting it with `evmClient.WriteReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow).
+- A complete project layout — `main.go`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source.
+
+If your CLF script also reads onchain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.CallContract()` replacement covered in the [Onchain reads](#onchain-reads) section above.
diff --git a/src/content/cre/reference/clf-migration-ts.mdx b/src/content/cre/reference/clf-migration-ts.mdx
new file mode 100644
index 00000000000..d09bae921f8
--- /dev/null
+++ b/src/content/cre/reference/clf-migration-ts.mdx
@@ -0,0 +1,287 @@
+---
+section: cre
+date: Last Modified
+title: "Migrate from Chainlink Functions to Chainlink CRE"
+pageId: "clf-migration"
+sdkLang: "ts"
+metadata:
+  description: "Migrate from Chainlink Functions (CLF) to Chainlink CRE. Concept mapping, chain support, triggers, task authoring, secrets, onchain writes, deployment, and monitoring."
+  datePublished: "2026-05-11"
+  lastModified: "2026-05-11"
+---
+
+import { Aside } from "@components"
+
+<Aside type="note" title="SDK Language: TypeScript">
+  You're viewing the **TypeScript** version of this guide. If you prefer Go, use the language selector in the left
+  sidebar to switch to the Go version.
+</Aside>
+
+This guide is for developers with production [Chainlink Functions (CLF)](/chainlink-functions) subscriptions migrating their requests to the [Chainlink Runtime Environment (CRE)](/cre) before mainnet shutdown on **August 12, 2026**.
+
+The majority of CLF use cases involve fetching off-chain data over HTTP and returning it to a consumer contract. That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer.
+
+## How CLF and CRE differ
+
+In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback.
+
+In CRE, the unit of execution is a [**workflow**](/cre/key-terms#workflow) - a TypeScript (or Go) project compiled to WebAssembly and registered with the network. Workflows are started by [**triggers**](/cre/key-terms#trigger) (cron schedule, HTTP request, or onchain log event), can perform multiple steps (HTTP fetches, onchain reads, onchain writes, calls to other [capabilities](/cre/key-terms#capability)) wrapped in your own business logic, and write data onchain through a signed-report flow that any contract implementing `IReceiver` can consume.
+
+Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an offchain relayer collapse into a single workflow.
+
+## Chain support
+
+CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported.
+
+For the canonical, up-to-date list of supported chains, see [Supported Networks](/cre/supported-networks-ts).
+
+## Terminology
+
+| Chainlink Functions                                 | Chainlink CRE                                                              |
+| :-------------------------------------------------- | :------------------------------------------------------------------------- |
+| `FunctionsClient` consumer contract                 | `IReceiver` consumer contract (use `ReceiverTemplate`)                     |
+| `_sendRequest()` from a consumer                    | EVM Log trigger (replaces on-chain entry path)                             |
+| Inline JavaScript source (Deno sandbox)             | TypeScript (or Go) workflow compiled to WASM (not compatible with node.js) |
+| `Functions.makeHttpRequest()`                       | `runtime.http.sendRequest()`                                               |
+| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver                             |
+| DON-hosted / remote-hosted secrets                  | Vault DON + `secrets.yaml` + `runtime.getSecret()`                         |
+| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `@chainlink/cre-sdk`, `cre-cli`, `cre-templates`                           |
+| Functions Playground UI                             | CRE CLI `cre workflow simulate`                                            |
+| Automation Time-based Upkeep → `sendRequest()`      | Built-in Cron trigger - no Automation upkeep needed                        |
+| `donId` + router address per chain                  | Chain selector + forwarder address per chain                               |
+
+## Configuration
+
+A CRE project is a standalone repository, not a string-encoded JavaScript source. The CLI (`cre`) scaffolds a project with the following files:
+
+- **`main.ts`** - workflow code: trigger registration, handler logic, and capability calls.
+- **`config.json`** - non-secret runtime configuration (API URLs, contract addresses, chain selectors).
+- **`secrets.yaml`** - secret declarations; values are supplied via `.env` files locally and via the Vault DON in production.
+- **`workflow.yaml`** - workflow metadata: name, owner, secrets path, and target network.
+- **`project.yaml`** - project-level CRE settings.
+
+There is no equivalent in CLF, where the entire program is a string passed directly to `_sendRequest()`.
+
+## Triggers
+
+CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, offchain trigger, reaction to an event) requires gluing CLF together with Automation, an offchain cron, or a custom indexer. CRE makes the [trigger](/cre/guides/workflow/using-triggers/overview) first-class.
+
+### Time-based
+
+Replaces "[Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) calling `sendRequest()`." Use a [cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-ts) directly.
+
+```ts
+const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" }) // every 5 min
+```
+
+Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix with `TZ=<timezone>` for timezone-aware scheduling.
+
+### Onchain events
+
+Directly replaces the on-chain entry path of `_sendRequest()`. Instead of your contract calling the DON, the DON watches for a specific event emitted by your contract (or any contract) and fires the handler with the decoded event data.
+
+```ts
+const evmClient = new cre.evm.EVMClient(CHAIN_SELECTOR)
+const trigger = evmClient.logTrigger({
+  addresses: [
+    /* base64-encoded contract address */
+  ],
+  topics: [
+    /* base64-encoded event signature hash */
+  ],
+})
+```
+
+### HTTP triggers
+
+Replaces patterns where an off-chain application or webhook would send a Solidity transaction solely to trigger a Functions request. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key.
+
+```ts
+const trigger = cre.capabilities.http.trigger({
+  authorizedKeys: [{ type: "EVM", key: "0xYourAuthorizedSigner" }],
+})
+```
+
+`authorizedKeys` is required for deployed workflows; an empty config is only valid in simulation.
+
+### Per-block triggers
+
+CRE does not offer a "fire on every block" trigger; for high-frequency onchain reactions, use the EVM Log trigger with a [`LATEST` confidence level](/cre/concepts/finality-ts). For periodic state polling, use a cron trigger and call `evmClient.callContract()` from the handler.
+
+## Task authoring and output
+
+<Aside type="caution" title="Determinism requirement">
+  CRE workflows run on multiple nodes that must reach consensus on a single result. Any code that produces different
+  output per node — `Date.now()`, `Math.random()`, non-deterministic iteration, or reading mutable global state — will
+  cause the workflow to fail at the consensus step. Review the [Avoiding
+  Non-Determinism](/cre/concepts/non-determinism-ts) guide before porting your CLF logic.
+</Aside>
+
+### Language and runtime
+
+CLF runs an inline JavaScript string in a per-request sandbox. Each request is independent; there is no project, no dependencies, and no compile step.
+
+CRE workflows are full TypeScript or Go projects compiled to WebAssembly. You manage dependencies with your standard package manager (like `npm` or `pnpm`) and run `cre workflow simulate` for a local execution that mirrors production.
+
+<Aside type="caution" title="WASM Compatibility">
+  Because workflows compile to WASM, they are not compatible with the Node.js runtime. Some common Node.js libraries
+  (like `fs`, `path`, or others that rely on native C++ bindings) will not work in a CRE environment. Ensure your
+  dependencies are WASM-compatible or browser-compatible.
+</Aside>
+
+The handler is single-threaded; SDK capability calls return an object that you resolve with `.result()` (TypeScript) or `.Await()` (Go).
+
+### HTTP / API calls
+
+Direct replacement for [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source). Supports GET and POST; consensus aggregation is automatic. See [API Interactions](/cre/guides/workflow/using-http-client) for full documentation.
+
+```ts
+const apiKey = await runtime.getSecret({ id: "API_KEY" }).result()
+
+const res = await runtime.http
+  .sendRequest({
+    url: "https://api.example.com/price",
+    method: "GET",
+    headers: { Authorization: `Bearer ${apiKey}` },
+  })
+  .result()
+
+const price = BigInt(Math.round(res.json().price * 100))
+```
+
+**Note:** 3xx redirects are not automatically followed; ensure you use the final resolved URL. For non-idempotent POSTs, set `cacheSettings` so the request is only executed once across the DON. Use `runtime.now()` (not `Date.now()`) for any timestamps included in a request payload.
+
+### Onchain reads
+
+CLF has no built-in onchain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call.
+
+CRE workflows can read on-chain state directly from within the handler using built-in connectivity:
+
+```ts
+const evm = new cre.evm.EVMClient(CHAIN_SELECTOR)
+const result = await evm
+  .callContract({
+    to: CONTRACT_ADDRESS,
+    data: encodeFunctionData({ abi, functionName: "latestAnswer" }),
+    blockNumber: cre.evm.LAST_FINALIZED_BLOCK_NUMBER,
+  })
+  .result()
+```
+
+You can also still use HTTP requests to interact with your own RPCs.
+
+### Onchain writes
+
+The on-chain write process represents the most significant structural change when migrating from CLF. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`.
+
+This process involves two steps: ABI-encode the payload and call `runtime.report()`, then submit the signed report with `evmClient.writeReport()`.
+
+```ts
+import { cre } from "@chainlink/cre-sdk"
+import { encodeAbiParameters } from "viem"
+
+export async function main() {
+  const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" })
+
+  cre.handler(trigger, async (runtime) => {
+    const apiKey = await runtime.getSecret({ id: "API_KEY" }).result()
+    const res = await runtime.http
+      .sendRequest({
+        url: "https://api.example.com/price",
+        headers: { Authorization: `Bearer ${apiKey}` },
+      })
+      .result()
+
+    const price = BigInt(Math.round(res.json().price * 100))
+    const payload = encodeAbiParameters([{ type: "uint256" }], [price])
+
+    const report = await runtime.report(payload).result()
+    const evm = new cre.evm.EVMClient(CHAIN_SELECTOR)
+    await evm
+      .writeReport({
+        receiver: RECEIVER_ADDRESS,
+        report,
+        gasLimit: "200000",
+      })
+      .result()
+  })
+
+  return cre.workflow()
+}
+```
+
+Receiver contract:
+
+```solidity
+import {ReceiverTemplate} from "@chainlink/cre-contracts/ReceiverTemplate.sol";
+
+contract PriceReceiver is ReceiverTemplate {
+  uint256 public price;
+
+  constructor(address forwarder) ReceiverTemplate(forwarder) {}
+
+  function _onReport(bytes calldata /* metadata */, bytes calldata payload) internal override {
+    price = abi.decode(payload, (uint256));
+  }
+}
+```
+
+Chain selectors and forwarder addresses are network-specific; see the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory-ts) and [Supported Networks](/cre/supported-networks-ts) for the values to substitute for `CHAIN_SELECTOR` and `RECEIVER_ADDRESS`. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) to learn how to permission your `IReceiver`.
+
+### Secrets
+
+CLF supports [DON-hosted secrets](/chainlink-functions/resources/secrets) (uploaded once via the Functions toolkit) and [user-hosted secrets](/chainlink-functions/tutorials/api-use-secrets-gist) (gist URL passed at request time). CRE [consolidates this through the Vault DON](/cre/guides/workflow/secrets).
+
+- **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var.
+- **Deployed:** upload to Vault DON via `cre secrets create`.
+- **In code:** `runtime.getSecret({ id: "API_KEY" }).result()` works the same in both environments.
+
+Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must register your secrets again using the `cre` CLI. See the [Project Configuration](/cre/reference/project-configuration-ts#33-secrets-configuration-secretsyaml) documentation for detailed instructions on managing secrets with the Vault DON.
+
+## Monitoring
+
+The [CRE dashboard](/cre/guides/operations/monitoring-workflows) provides per-workflow execution history, handler logs (via `runtime.log()`), per-step timings, [consensus](/cre/concepts/consensus-computing) outcomes, and onchain submission status, replacing the per-request views in the [Functions Subscription Manager](/chainlink-functions/resources/subscriptions). Failed executions and reverted onchain writes surface directly in the workflow detail view.
+
+## Deployment and lifecycle
+
+| Action            | Chainlink Functions                                                                                             | Chainlink CRE                                                                                                                                                              |
+| :---------------- | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Author code       | Inline JS string in your consumer contract                                                                      | TypeScript/Go project; `cre workflow init` to scaffold                                                                                                                     |
+| Local test        | [Functions Playground](/chainlink-functions/resources/simulation) / `simulateScript`                            | [`cre workflow simulate`](/cre/guides/operations/simulating-workflows)                                                                                                     |
+| Deploy            | Deploy `FunctionsClient` consumer; [create and fund subscription](/chainlink-functions/resources/subscriptions) | Deploy `IReceiver` consumer; [`cre workflow deploy`](/cre/guides/operations/deploying-workflows); [activate workflow](/cre/guides/operations/activating-pausing-workflows) |
+| Update logic      | Re-deploy consumer (source baked into requests) or update gist                                                  | [`cre workflow update`](/cre/guides/operations/updating-deployed-workflows) (workflow code only; receiver unchanged)                                                       |
+| Pause             | Cancel subscription / set consumer flag                                                                         | [`cre workflow pause`](/cre/guides/operations/activating-pausing-workflows)                                                                                                |
+| Delete            | Remove consumer; withdraw remaining LINK from the subscription                                                  | [`cre workflow delete`](/cre/guides/operations/deleting-workflows)                                                                                                         |
+| Manage secrets    | [DON-hosted upload](/chainlink-functions/resources/secrets) via toolkit, expires after threshold                | [`cre secrets create / update / delete`](/cre/guides/workflow/secrets) against Vault DON                                                                                   |
+| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only                                                       | [Built-in email alerts on workflow failures; UI showing executions and DON logs](/cre/guides/operations/monitoring-workflows)                                              |
+
+## Get started
+
+To begin your migration, follow the [CRE Getting Started guide](/cre/getting-started/cli-installation) to install the CLI and initialize your first project.
+
+When mapping your existing CLF script:
+
+- Use `cre workflow init` to scaffold your project.
+- Replace your `_sendRequest()` logic with the appropriate [Triggers](#triggers) and [handler logic](#task-authoring-and-output).
+- Deploy a `ReceiverTemplate`-based consumer contract to receive reports.
+- Test your logic locally with `cre workflow simulate` before deploying with `cre workflow deploy`.
+
+Migrate your workflows one at a time and decommission your CLF subscriptions only after confirming the CRE workflows are successfully producing reports on-chain.
+
+For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo.
+
+### Reference template for CLF migration
+
+The closest one-to-one mapping for the typical CLF use case ("fetch offchain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both TypeScript and Go:
+
+- [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts)
+- [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go)
+
+It demonstrates each piece of the migration end-to-end:
+
+- A [**cron trigger**](/cre/guides/workflow/using-triggers/cron-trigger-ts) scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a [**log trigger**](/cre/guides/workflow/using-triggers/evm-log-trigger-ts) variant (replaces an offchain listener reacting to an onchain event).
+- An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.getSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets).
+- ABI-encoding the result, calling `runtime.report()` to produce a signed report, and submitting it with `evmClient.writeReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow).
+- A complete project layout — `main.ts`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source.
+
+If your CLF script also reads onchain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.callContract()` replacement covered in the [Onchain reads](#onchain-reads) section above.
diff --git a/src/features/chainlink-automation/common/ChainlinkAutomation.astro b/src/features/chainlink-automation/common/ChainlinkAutomation.astro
index bf4bc6b154b..f2ae77c1b24 100644
--- a/src/features/chainlink-automation/common/ChainlinkAutomation.astro
+++ b/src/features/chainlink-automation/common/ChainlinkAutomation.astro
@@ -2,7 +2,7 @@
 import StreamsLookupInterfaceComponent from "./StreamsLookupInterface.mdx"
 import ILogAutomationComponent from "./iLogAutomation.mdx"
 import DeprecationCalloutComponent from "./deprecation.mdx"
-import CreCalloutComponent from "./cre-callout.mdx"
+import CreCalloutComponent from "./cre-callout-automation.mdx"
 
 export type Props = {
   section?: "ilogautomation" | "streamslookup"
diff --git a/src/features/chainlink-automation/common/cre-callout-automation.mdx b/src/features/chainlink-automation/common/cre-callout-automation.mdx
new file mode 100644
index 00000000000..3d34ef39ee5
--- /dev/null
+++ b/src/features/chainlink-automation/common/cre-callout-automation.mdx
@@ -0,0 +1,7 @@
+import { Aside } from "@components"
+
+<Aside type="tip" title="Integrating offchain computation or data?">
+  Check out the [Chainlink Runtime Environment (CRE)](/cre), our latest environment for building and running verifiable
+  workflows with enhanced capabilities, improved developer experience, and support for everything Chainlink Functions
+  can do—and more.
+</Aside>
diff --git a/src/features/chainlink-functions/common/cre-callout.mdx b/src/features/chainlink-functions/common/cre-callout.mdx
index 3d34ef39ee5..57b7854c50e 100644
--- a/src/features/chainlink-functions/common/cre-callout.mdx
+++ b/src/features/chainlink-functions/common/cre-callout.mdx
@@ -1,7 +1,9 @@
 import { Aside } from "@components"
 
-<Aside type="tip" title="Integrating offchain computation or data?">
-  Check out the [Chainlink Runtime Environment (CRE)](/cre), our latest environment for building and running verifiable
-  workflows with enhanced capabilities, improved developer experience, and support for everything Chainlink Functions
-  can do—and more.
+<Aside type="caution" title="Chainlink Functions is shutting down on August 12, 2026">
+  Chainlink Functions will stop processing requests after **August 12, 2026**. Migrate your workflows to the
+  [Chainlink Runtime Environment (CRE)](/cre) before this date to avoid service interruption.
+
+See the [CLF to CRE migration guide](/cre/reference/clf-migration) for a full concept mapping and code examples.
+
 </Aside>
diff --git a/src/layouts/DocsLayout.astro b/src/layouts/DocsLayout.astro
index 372264417ed..87da22d109d 100644
--- a/src/layouts/DocsLayout.astro
+++ b/src/layouts/DocsLayout.astro
@@ -14,6 +14,7 @@ import { detectApiReference } from "@components/VersionSelector/utils/versions"
 import { LanguageSwitcherDropdown } from "~/components/LanguageSwitcherDropdown"
 import { ChainTypeSelector } from "~/components/ChainSelector"
 import { isChainAwareSection } from "~/config/chainTypes"
+import CLFShutdownCallout from "~/features/chainlink-functions/common/cre-callout.mdx"
 
 interface Props {
   frontmatter: BaseFrontmatter
@@ -99,6 +100,7 @@ const howToSteps = initialHeadings
         {isApiReference && product && isVersioned && <VersionSelector product={product} currentPath={currentPage} />}
 
         <PageContent {titleHeading}>
+          {frontmatter.section === "chainlinkFunctions" && <CLFShutdownCallout />}
           <slot />
         </PageContent>