Copilot Studio: Export an Agent and Preserve Its Work

To export a Copilot Studio agent through Microsoft’s solution-based path, put it in a custom solution, export that solution, and import it at the destination. Check the package and its dependencies before treating the move as complete; a downloaded file alone does not prove the destination works.

Keep a separate record of the reason for the move, completed checks, and remaining work. fenbs can hold that reviewed project record, while Microsoft handles the agent package. fenbs does not connect to Copilot Studio or import its agent exports.

How do you export the agent through a solution?

Microsoft describes this route for agents using its standard runtime in the agent export and import instructions↗ (opens in a new tab). Confirm that the procedure applies to your agent, then identify the source and destination environments.

1. Open Solutions in the source environment and create or open a custom unmanaged solution.
2. Choose Add existing, then Agent, then Agent again. Select the agent and add it.
3. Review the components and dependencies described below before choosing Export solution.
4. Complete the export prompts and save the resulting package in your approved storage location.
5. Record the solution version, source environment, export date, and intended destination beside the file.

An unmanaged solution is the editable source container. Microsoft explains custom solution management↗ (opens in a new tab), including how to open the solution explorer and create that container. Keep the source available for later corrections rather than making the download your only working copy.

What should you expect the package to leave behind?

The agent instructions are included, but Microsoft warns that some separately stored topics or knowledge sources might not be. Topic and node comments do not export, and some identifiers, channel details, or presentation elements may not transfer. Check the linked export instructions for the current boundaries.

Make an inventory instead of using the word everything. Separate the design you expect in the package from the external resources it needs and the human record explaining it. That makes a missing resource an explicit check rather than a surprise after someone starts using the agent.

For terminology, start with our Copilot Studio overview. The distinction between the builder and its wider audience is covered in Microsoft Copilot agents.

How do you avoid missing dependencies?

A dependency is another component the agent needs to work. Microsoft’s missing-component troubleshooting guide↗ (opens in a new tab) explains why later source changes do not automatically appear in an earlier imported copy. In the source solution, locate the agent, select Advanced, then Add required objects before exporting the updated solution.

Repeat that review when you add components, including tools or flows. Check the solution context in which you author changes; the troubleshooting guide describes preferred solutions and opening an agent from the intended solution. Keeping that association clear makes repeated moves easier to inspect.

Custom connectors need particular care. Microsoft’s connector migration guidance↗ (opens in a new tab) says to import them before their connection references or flows, using a separate connector solution when necessary. Credentials must be entered again and connections created; connector role assignments also need attention in the destination.

Give each dependency a named checker. For example, one teammate can verify the knowledge location while another confirms the destination connector account. Record the result as passed, failed, or not checked. A list with named checks is more useful than an unqualified statement that the agent was exported successfully.

What must you check during import?

At the destination, use Import solution and review every prompt. Microsoft’s solution import documentation↗ (opens in a new tab) describes choosing destination connections, supplying environment-variable values when prompted, and handling missing dependencies. An environment variable is a named setting that can differ between environments, such as a service address.

Check each displayed value against the intended destination. A successful import that still points to a development resource can produce the wrong result. Avoid solving uncertainty by accepting whichever connection is already selected; confirm who owns it and which service it reaches.

If import fails, download its log and preserve the exact error with the package version. Resolve the stated dependency in the source or destination as appropriate, then retry deliberately. Repeatedly exporting under new file names without identifying the missing component makes it harder to know which package anyone tested.

How do you prove the moved agent is usable?

Reconfigure user authentication after import, as Microsoft’s agent import instructions↗ (opens in a new tab) direct, and publish the imported agent before sharing it. Keep the publishing procedure separate from the package move; our Copilot Studio publishing guide covers that neighboring task.

• Run a representative question and compare its answer with the intended knowledge source.
• Test an allowed action against an approved test record, and confirm which system changed.
• Check access with the kind of account the intended audience will use.
• Try a refusal or unavailable-resource case so the failure is understandable.
• Record the actual result, checker, and remaining limits before calling the move complete.

Say you are moving an internal help agent. A good test says which sample request it answered, which reference it used, and whether its follow-up action reached the test system. “It opened” proves much less. Keep untested behavior visible in the handoff so the next teammate does not inherit an accidental promise.

Where should the decisions and remaining work live?

Keep a short work record outside the package: why this version was chosen, what changed, which checks passed, and what happens next. Include a reference to the approved package location without putting credentials or sensitive connection details in that record.

This is separate from the agent’s design instructions or a coding assistant’s configuration; GitHub Copilot agents versus skills explains that nearby terminology. fenbs keeps the project’s reviewed handoff record available when a person or supported assistant changes.

How to do this with fenbs

1. Create a free account, then add a project for the agent and its move.
2. Add a task with the source, intended destination, package reference, and dependency checks. Update its plan as you learn what the move requires.
3. Record the decisions a person approved, including which version should move and why. Keep unanswered choices open.
4. Save completed checks, failed checks, and the next action in Where we left off. Use a team kanban board with suitable member roles when colleagues need access.
5. If you use a supported assistant, follow Integrations, ask it to read the project context first, and save progress before it stops.

fenbs is not the right fit for executing solution deployment or restoring an agent. Use Microsoft’s tools for those jobs; use the shared work record when someone needs to understand and continue what remains. The AI handoffs hub covers other transitions between people and assistants.