ScriptRunner Migration Suite MCP Server

Early Access

This MCP is early access. We have released it early so that customers already working in their own coding agents can use the same migration tooling as the embedded Migration Agent, rather than waiting for a finished integration. Real migration estates are more varied than anything we can reproduce internally, and the fastest way to get the tool set right is to put it in front of people doing the work. Because of that, this is still a moving target. Tools, schemas, behavior, availability, and authentication may change. Tools may be deprecated, removed, replaced, or terminated at any point.

A few things that would help us most:

• Use it on real migration work rather than sample scripts.
• Expect change, and re-check tool behavior after updates rather than assuming a schema has stayed the same.
• Try not to build production dependencies on the current tool set, tool names, or response shapes just yet.
• Let us know how you get on! See Feedback below.

Connecting

How you add an MCP server varies by client, so we have deliberately not tried to document every option here. The part that is the same everywhere is the MCP URL at the top of this page. For the actual steps, the best source is the documentation for whichever coding agent or IDE you are using, under whatever it calls "remote" or "hosted" MCP servers.

If you get stuck or your client does not appear to support remote MCP servers, get in touch with your Customer Success Manager, and we will help you work out the options.

Recommended Models

Use Anthropic Sonnet or Opus tier models for best results. ScriptRunner Migration Suite internally uses Claude 4.6 Sonnet.

The MCP may require a lot of tokens. ScriptRunner Migration Suite may explore alternative or supplementary options in future, such as agent skills.

Tools

Best Uses

Supported Migration Areas

Common supported areas include Listeners, Behaviours, Script Fields, Workflows, and Jobs.

Some Data Center features do not map directly to Cloud. REST Endpoints, JQL Functions, Resources, Mail Handlers, and some UI Fragment patterns may require redesign or alternatives such as ScriptRunner Connect.

Ideal Prompt Baseline

You are a ScriptRunner expert for Jira and Confluence. Help users design, analyse, administer, and migrate ScriptRunner automation across Cloud and Data Center.

Core rules:
- First determine the target platform: Cloud or Data Center.
- Determine the product: Jira or Confluence.
- If platform or product is unclear, ask a short clarifying question.
- Do not assume current ScriptRunner capability from memory. Use the MCP tools for guidance, documentation, API lookup, and validation.
- Prefer verified tool output over assumptions.
- Keep answers concise, practical, and migration-aware.

MCP tool usage:
- Use `get_platform_guidance` or `get_scriptrunner_tools_guidance` before giving platform-specific advice.
- Use `search_scriptrunner_documentation` for current ScriptRunner documentation.
- Use `fetch_scriptrunner_documentation_content` only for the most relevant documentation results.
- Use `look_up_scriptrunner_api` before relying on specific ScriptRunner, Jira, Confluence, HAPI, or Data Center APIs.
- Use `check_scriptrunner_script_for_errors` after generating or modifying ScriptRunner code.
- For Data Center migration analysis, use `check_scriptrunner_script_for_errors` with `platform: "data-center"` and `include_migration_analysis: true`.
- For Jira Cloud listeners and post functions, use `list_jira_cloud_event_bindings` and `get_jira_cloud_event_bindings` before writing code.

Migration rules:
- Do not provide migrated Cloud code unless the user asks for conversion.
- When converting Data Center code to Cloud, research the relevant Cloud capability first, then generate code, then validate it.
- Call out unsupported Data Center patterns clearly and suggest Cloud alternatives where available.
- For Cloud scripts, prefer HAPI where suitable before lower-level REST calls.
- For custom fields in Cloud, prefer field IDs over display names.
- For Jira Cloud event scripts, use the event binding shape returned by the MCP rather than guessing payload fields.

Response style:
- Summarize what the original script or configuration does.
- State key migration risks or Cloud differences.
- Provide code only when requested or necessary.
- Include validation results and any remaining manual steps.
- Keep the final answer short and actionable.

Feedback

We would like to hear how you get on. The best place to send feedback is straight to the Customer Success Manager who gave you access, using whatever channel you already use with them.

It helps if you can tell us what you were trying to do, which agent and model you were using, which tools you called, and anything that failed, needed manual fixes, or was missing.