Many Workday customers run on Studio integrations written years ago by people who have since moved on. Workday Developer Agent, generally available since October 13, 2026, makes a rebuild look tempting: describe the outcome and it builds Workday Extend objects for "serverless functions and cross-system orchestrations" that connect Workday with other systems.

A rebuild is a project, not a prompt. This post gives a practical way to decide which integrations to move, which to leave in Studio and how to migrate the ones that move.

Three kinds of integration

Sort your Studio inventory into three groups. The playbook for inherited Studio integrations covers how to build the inventory if you do not have one.

1. Rebuild as an orchestration

Good candidates are event-driven or request-driven integrations that call modern REST APIs with modest volumes:

  • sending a new hire to an identity or IT provisioning system;
  • posting a notification or ticket when a business process completes;
  • looking up data in an external system to enrich a Workday transaction.

The guide to Orchestrate vs. Studio applies here. Developer Agent's ability to build orchestrations from a description makes these the quickest wins, and they become easier for the next team to read and change.

2. Rebuild as a custom agent (or add one beside it)

Some integrations exist because a person had to make a judgement and the integration did the typing. Examples include matching records that do not quite line up, triaging exceptions and preparing data for someone to approve. Those steps may be better served by a custom agent that does the analysis and asks a person to confirm.

Do not replace a deterministic integration with an agent just because you can. If the logic is a fixed rule, keep it a rule.

3. Leave in Studio for now

Keep these in Studio until there is a strong reason to move:

  • high-volume file-based outbound integrations, such as payroll and benefits carrier files;
  • integrations with complex transformation logic that is tested and stable;
  • anything with regulatory or contractual file formats where a byte-level change is a risk.

"Old" is not a reason to migrate. "Fragile, undocumented and changing often" is.

Migrating one integration safely

  1. Capture today's behaviour first. Run the existing integration in a non-production tenant and keep its outputs for a known set of inputs. That is your reference.
  2. Describe the outcome, not the old code. Give Developer Agent the business purpose, the systems, the data and the error handling you need. A literal translation of a decade-old assembly carries its workarounds with it.
  3. Review the result. Check fields, security, credentials and retry behaviour with the Developer Agent review checklist.
  4. Compare outputs side by side. Run the new orchestration on the same inputs in non-production and compare with the reference. Differences are either bugs or intended fixes; decide which in writing.
  5. Run both in parallel, then switch. For anything that matters, run old and new together for a cycle before retiring the Studio integration.
  6. Budget the run cost. Developer Agent and Workday's agent capabilities are priced in Flex Credits. Ask how the new orchestration's runs are metered before you retire a Studio integration that cost nothing extra to run.

Where kiweely fits

kiweely is a desktop co-pilot for Workday consultants that works on both sides of this decision. It can open and work with Studio integrations in your own installed Workday Studio, so you can understand, test and fix what exists today. It also builds, validates and deploys Workday Extend apps to a client's Development environment and tests them in the browser. It connects to each client's tenants separately, asks for your consent before every change and runs on the ChatGPT or Claude account you connect. That lets the same consultant document the old integration, build its replacement and compare the two, without needing to be a developer.