# Migrate an application to Azion An application that runs on another provider has an origin, a domain, and rules that shape its traffic. Migrating it to Azion means rebuilding that chain on the platform and moving the domain last, so the application keeps serving while you work. You register the origin as a [connector](/en/documentation/platform/connectors/), serve it through an [application](/en/documentation/platform/applications/), expose it on a [workload](/en/documentation/platform/workloads/), and point the domain at the workload. If you are leaving one of the providers below, follow its guide instead. Each one maps the provider's services to their Azion equivalents. | Provider | The guide covers | | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Akamai](/en/documentation/guides/platform/migration/akamai-migration-guide/) | Properties, EdgeWorkers, Cloudlets, redirects and headers, cache, load balancing, image and media delivery, EdgeKV, NetStorage, databases, WAF, DDoS protection, bots, rate limits, monitoring, mPulse, certificates, and DNS | | [AWS](/en/documentation/guides/platform/migration/aws-migration-guide/) | CloudFront, Lambda, API Gateway, Step Functions and EventBridge, cache, load balancing, images, Bedrock, DynamoDB, ElastiCache, S3, RDS and Aurora, WAF, Shield, bots, rate limits, CloudWatch, X-Ray, certificates, and Route 53 | | [Cloudflare](/en/documentation/guides/platform/migration/cloudflare-migration-guide/) | Pages, Workers, redirects and headers, cache, load balancing, images, Workers AI, Workers KV, R2, D1, WAF, DDoS protection, bots, rate limits, analytics and logs, certificates, and DNS | | [Fastly](/en/documentation/guides/platform/migration/fastly-migration-guide/) | Services, Compute, VCL, redirects and headers, cache, load balancing, Image Optimizer, streaming and WebSockets, KV stores, Object Storage, Next-Gen WAF, DDoS protection, bots, rate limits, logging, and certificates | | [Vercel](/en/documentation/guides/platform/migration/vercel-migration-guide/) | Projects, functions, redirects and headers, cache, images, AI routes, Edge Config, Blob, firewall, bots, rate limits, account access, observability, Speed Insights and Web Analytics, certificates, and DNS | --- ## Prerequisites - An Azion account. To open one, refer to [Create an account](/en/documentation/fundamentals/creating-account/). - The address of the current origin: a host name, an IPv4 or IPv6 address, or an [Object Storage](/en/documentation/platform/object-storage/) bucket. - Access to the DNS records of the domain at your DNS provider. - (Optional) The [Azion CLI](/en/documentation/devtools/cli/), for local development and deployment. > **Note** > > With the **Business** support plan or higher, [Integration Services](/en/documentation/services/integration-services/) gives you access to Azion specialists during the migration. For the plans, refer to [Azion Support](https://www.azion.com/en/professional-services/). --- ## Register the origin as a connector A connector tells Azion where to fetch the content and code of the application. To create it in Azion Console: 1. **Open the Connectors page** Access [Azion Console](https://console.azion.com/) > **Connectors**. 2. **Select + Connector** 3. **Select the connector type** In **Connector Type**, select *HTTP* for a host name or an IP address, or *Object Storage* for a bucket. 4. **Enter the origin** In **Address**, enter the origin address. If the origin answers to a virtual host that differs from that address, enter it in **Host Header**. 5. **Select Save** The connector is ready to be set as the origin of the application. For the remaining connection options, refer to [Connectors](/en/documentation/platform/connectors/). --- ## Create the application The application holds the rules, the cache settings, and the functions that serve the content. To start from a template, open [Templates and Integrations](/en/documentation/platform/marketplace/) and deploy one; the [Azion Starter Kit](/en/documentation/guides/application-development/frameworks/azion-starter-kit/) gives you a basic project to explore the platform, and the [full list of templates](/en/documentation/platform/marketplace/templates/) covers the common frameworks. To start from your own code, refer to [Applications quickstart](/en/documentation/platform/applications/quickstart/). To route the application to the connector: 1. **Open the application** Access [Azion Console](https://console.azion.com/) > **Applications** > **your application**. 2. **Open the Rules Engine tab** 3. **Edit the default rule** Edit the default rule, or add a rule for the request phase. 4. **Set the criteria** In **Criteria**, set **If `${uri}` starts with `/`**, so the rule covers the whole application. 5. **Set the behavior** In **Behavior**, select **Set Connector** and select the connector. 6. **Select Save** Requests that reach the application are now fetched from the connector. For the other settings, refer to [Applications](/en/documentation/platform/applications/). --- ## Expose the application on a workload A workload gives the application its Azion domain and receives the custom domain later. To create it: 1. **Open the Workloads page** Access [Azion Console](https://console.azion.com/) > **Workloads**. 2. **Select + Workload** 3. **Name the workload and choose the infrastructure** Enter a **Name**. In **Infrastructure**, select *Production*. This choice cannot be changed after the workload is saved. 4. **Enter the custom domain** In **Subdomain** and **Domain**, enter the host name the application answers to. For example: `www` and `example.com`. 5. **Select the application** In **Applications**, select the application. 6. **(Optional) Select a firewall** In **Firewall**, select the firewall that protects the application. 7. **Select the certificate** In **Digital Certificate**, select the certificate for the domain, or the Azion SAN certificate to use the workload domain. 8. **Select Save** Azion generates the workload domain, in the format `xxxxxxxxxx.map.azionedge.net`. It is the address the custom domain will point to. --- ## Test the application before moving the domain While the public DNS still points to the current provider, your computer can reach the application on Azion through its `hosts` file. This is where a misconfiguration from the migration shows up before any user sees it. To stage the application: 1. Resolve the workload domain to find the addresses that serve it: ```bash host xxxxxxxxxx.map.azionedge.net ``` The response lists the domain and one or more addresses: ```bash xxxxxxxxxx.map.azionedge.net has address 200.0.0.0 ``` 2. In the `hosts` file of your computer, add a line that maps the custom domain to one of those addresses. 3. Open the custom domain in a private browser window, so a cached DNS answer does not send you to the current provider. The application loads from Azion under its own domain. For the location of the `hosts` file on each operating system, refer to [Test an application through the hosts file](/en/documentation/guides/application-development/getting-started/stage-applications-through-hosts-file/). --- ## Point the domain to the workload The DNS change is the switch: once the domain resolves to the workload, users reach the application through Azion. To point the domain: 1. Sign in to your DNS provider and open the records of the domain. 2. Create or edit the CNAME record of the subdomain, pointing it to the workload domain: | Name | Value | Type | | ----- | ------------------------------ | ----- | | `www` | `xxxxxxxxxx.map.azionedge.net` | CNAME | 3. Save the record. DNS changes take time to propagate. To check what the resolvers answer, refer to [How to look up DNS servers with Dig command](/en/documentation/guides/application-security/dns/run-the-dig-command/). > **Note** > > A domain apex cannot hold a CNAME record at every provider. To point the apex, [migrate the nameservers to Azion](/en/documentation/guides/platform/migration/migrate-ns-to-azion/). For the Console settings of the custom domain, refer to [Point a domain to a workload](/en/documentation/guides/platform/migration/point-domain-to-azion/). --- ## Next steps - [Real-Time Metrics](/en/documentation/platform/real-time-metrics.md): Follow requests, data transferred, status codes, and cache offload in dashboards and the GraphQL API. - [Real-Time Events](/en/documentation/platform/real-time-events.md): Read the logs of requests, functions, and WAF events to troubleshoot the migrated application. - [Web Application Firewall](/en/documentation/platform/firewall.md#waf): Protect the application against SQL injection, XSS, and other application-layer attacks. - [DDoS Protection](/en/documentation/platform/workloads.md#ddos-protection): Understand the always-on protection against volumetric and protocol attacks. - [Functions](/en/documentation/platform/functions.md): Run code on the request path of the application. - [Rules Engine](/en/documentation/platform/applications/rules-engine.md): Rebuild the traffic rules of the previous provider.