Migrate from VisualCron
This guide moves VisualCron Jobs to Windmill, one Job at a time. Your AI coding agent (Claude Code, Codex or Cursor) reads the Jobs exported from your VisualCron Server and rebuilds each one as a Windmill flow or script, with its schedule or trigger. For how the two tools compare, see Windmill vs VisualCron.
Most VisualCron Jobs touch Windows: PowerShell, local and network paths, .exe files, Windows accounts.
In Windmill, those steps run on Windows workers, a Self-Hosted Enterprise feature.
Steps that only call APIs or databases can run on Linux workers, on Windmill Cloud or on any self-hosted instance.
1. How VisualCron stores Jobs
In VisualCron, a Job runs when one of its Triggers fires, and "when a Job runs, it runs its Tasks". Each Job has one or more Tasks, and each Task has a Task type, such as starting a program, copying files or running a SQL query. Triggers are Time Triggers or Event Triggers, and a Flow on the Job or a Task decides what happens on start, error, success and completion. Credentials (Windows accounts), Connections (addresses and sign-ins for other systems) and Variables are global objects that Tasks refer to.
The Server keeps all of this in its settings folder: "the Server settings, Jobs and other objects". Export settings saves them to one zip file, and lets you choose which object types to include.
2. Export your Jobs
- In the VisualCron Client, open File > Import/Export > Export settings.
- Under Select settings, select Jobs, and Variables if your Jobs use them. Leave Credentials and Connections out: VisualCron warns that the file holds the selected Credentials, Connections, Certificates and keys, and you will recreate them in Windmill yourself.
- Choose Custom file path, leave Password empty, and click Start.
- Unzip the file into an empty folder, for example
visualcron-export/.
If you would rather not give the agent the export, you can also describe a Job to it from the Client: the Task list, each Task's settings and the Triggers tab.
3. Give your agent one prompt
Open the folder that contains visualcron-export/ in Claude Code, Codex or Cursor, and paste:
Migrate my VisualCron Jobs to Windmill.
1. If this folder has no wmill.yaml, run `npx -y windmill-cli@latest init --use-default`.
2. Read the skills that init installed under .claude/skills, and the mapping in
https://www.windmill.dev/docs/misc/guides/migrate_from_visualcron
3. Read the VisualCron export in ./visualcron-export/. Write visualcron_migration.md with one
entry per Job: its Triggers, its Tasks in order with their Task types, the Credentials,
Connections and Variables it uses, and anything with no direct Windmill equivalent.
4. Ask me which folder to use, which Jobs to migrate, and which worker tag runs Windows steps.
5. Rebuild each Job I pick as a flow (or a single script for a one-Task Job), with its
schedule created disabled.
Don't deploy anything until I've reviewed it.
All you need installed is Node.js, for npx.
wmill init sets up a local Windmill project, with no account needed, and installs the AI skills for writing flows, PowerShell, C# and MS SQL scripts, schedules, triggers and resources.
Check visualcron_migration.md before the agent converts anything: it is the list of what moves, what needs a decision, and what you bring over by hand.
4. Connect a workspace and preview
To run the converted flows, you need a Windmill workspace: sign up for Windmill Cloud, or self-host Windmill and add a Windows worker for Windows steps. Connect the workspace from your own terminal:
npx windmill-cli workspace add
The agent can then preview each flow with sample inputs and fix what fails. A preview deploys nothing, but it does run the steps, so point it at test systems where a Job writes or deletes data.
5. Bring over what the export leaves out
| VisualCron | Where it goes in Windmill |
|---|---|
| Credential (a Windows account a Task runs as) | The account the Windows worker's service runs as. To run steps as different accounts, run one worker service per account, each listening to its own tag |
| Connection | A resource, for example an ms_sql_server resource for a SQL Connection |
| Passwords and API keys | Secret variables |
| Variable | A variable for a fixed value; for a value one Task passes to the next, the previous step's result (results.<step id>, see flow architecture) |
| Job group | A folder |
6. Review, deploy and switch over
- Review the flows and scripts in
f/<your folder>/and the checklist. - Deploy the folder with its schedules and triggers:
wmill sync push --includes 'f/<your folder>/**' --include-triggers --include-schedules. - For each Job, deactivate it in VisualCron and enable its Windmill schedule. Keep the VisualCron Job until the Windmill runs match.
How VisualCron concepts map to Windmill
| VisualCron | Windmill |
|---|---|
| Job | Flow, or a single script for a one-Task Job |
| Task | A flow step |
| Time Trigger | Schedule with a cron expression |
| HTTP REST Event Trigger | Webhook or HTTP route |
| Mail Trigger | Email trigger, if mail can be forwarded to its address, or a scheduled poll that reads the mailbox |
| File, Folder, Remote file, Cloud file, SQL and HTTP Triggers | A scheduled poll: a trigger script on a schedule that keeps state and returns only new items |
| Amazon SQS and AMQP Triggers | SQS triggers (self-hosted Enterprise) and AMQP triggers (self-hosted) |
| Service, Registry, Event log, Performance counter and other Windows Event Triggers | No built-in equivalent. A scheduled script on a Windows worker checks the condition, or a Windows-side task calls the flow's webhook |
| Job or Task Flow on error | Retries, a flow error handler, and a schedule error handler (Cloud and Enterprise) |
| Execute Task (command or batch) | A PowerShell script on a Windows worker, or Bash on a Linux worker |
A compiled .exe with no source | Run it as it is from a PowerShell script on a Windows worker that has the file, for example & 'C:\Tools\export.exe' --day $day, and fail the step when $LASTEXITCODE is not 0 |
| PowerShell Task | A PowerShell script. Its param() block becomes the script's inputs and Import-Module installs missing modules (details). Windows workers run PowerShell 7 (pwsh.exe), so check scripts written for Windows PowerShell 5.1 |
| .NET Code Execute Task | A C# script with NuGet dependencies. Windmill has no VB.NET runtime, so VB.NET code is rewritten in C# or PowerShell |
| SQL Task | An MS SQL script (Enterprise Edition or Cloud), with Windows integrated authentication on a Windows worker. A SQL Server Agent job becomes EXECUTE msdb.dbo.sp_start_job N'<job name>'; |
| Execute SSIS package and Execute SSISDB package Tasks | dtexec from a PowerShell script on a Windows worker where SSIS is installed, or a SQL Server Agent job started with sp_start_job; see Windmill vs SSIS |
| SSRS Task | No built-in equivalent. A script requests the report from the report server with URL access and rs:Format (for example PDF or EXCELOPENXML), then saves the file to object storage or sends it. On a Windows worker, PowerShell's Invoke-WebRequest -UseDefaultCredentials signs in as the worker's account |
| Email Task | A step that sends mail through an SMTP resource |
| Other Task types (files, FTP, cloud storage, Active Directory) | A script in the language that suits it, using that system's API, SDK or PowerShell module. Steps that use local or network paths run on a Windows worker |
Getting help
If part of a Job doesn't convert, or a migrated flow behaves differently from the VisualCron Job, ask us on Discord or email [email protected].
Include the Job's entry from visualcron_migration.md.