Do you want to replace Netlify with a controllable hosting and deployment path? WZ-IT provides PaaS migration from EUR 1,990 excluding VAT to Coolify, static hosting or another suitable target architecture.
A migration from Netlify to Coolify or European hosting can range from a simple static move to application replatforming. The deciding factor is whether Netlify only builds and serves files or also provides functions, forms, previews, identity, edge logic and other platform services.
Capture Netlify usage completely
The inventory covers:
- repository, branch and build command
- publish directory and generated artifacts
- runtime, build and plugin dependencies
- environment variables by context
- production and branch deployments
- deploy previews and approval process
- functions and potentially edge functions
- forms, spam protection and notifications
- redirects, rewrites, proxies and headers
- domains, DNS, TLS and external APIs
- data, identity and further integrations
Repository configuration is an important source, but may omit dashboard settings and external services.
Static website or dynamic application?
For a purely static site, target operations consist of build, artifact, web delivery, TLS, caching and monitoring. Coolify is possible but not always necessary. A small web server or object storage with controlled delivery may be sufficient.
Functions, forms or server-side framework capabilities introduce a runtime layer. Endpoints, secrets, data, time limits, dependencies, logging and scaling then need separate design.
| Netlify capability | Possible target mapping |
|---|---|
| Static deploy | web server, object storage or Coolify application |
| Deploy preview | dedicated preview or staging environment |
| Function | API endpoint, separate service or application route |
| Edge function | normal server runtime or selected edge component |
| Forms | own form service with validation and notifications |
| Redirects/headers | reverse-proxy or web-server configuration |
| Environment variables | separated platform variables or secret management |
Make the build reproducible
The build must work outside Netlify from a defined commit. Capture runtime version, package manager, lockfile, build command, plugins, system libraries and required variables. Version the generated artifact or deploy it through a reproducible container.
Build plugins can add Netlify-specific behaviour. Determine whether they only execute build steps or provide capabilities that need a different target implementation.
Replace functions, forms and integrations
For every function capture trigger, runtime, route, secrets, data access, duration, failure behaviour and logs. Some functions can join the main application; others remain better isolated as a service or worker.
Netlify Forms combines HTML detection with storage, spam protection and notifications. These capabilities need an explicit target implementation, including privacy, recipients, retention and abuse protection.
Test redirects, headers and domains
Do more than translate syntax. Validate:
- exact and wildcard rules
- permanent and temporary status codes
- rewrites and proxy targets
- single-page-application fallbacks
- Cache-Control and security headers
- language and legacy URLs
- certificates, IPv4/IPv6 and DNS TTL
Automated URL tests before cutover protect against silent SEO and routing defects.
Previews, staging and cutover
Deploy Previews can become short-lived environments or a fixed staging setup. Balance the required convenience against data access, secrets, cost and clean-up. Production moves only after builds, functions, forms, redirects, external APIs, logs and monitoring have been validated on the target.
If it is unclear which Netlify services actually need porting, the PaaS Exit Review establishes a sound scope before implementation.
