Engineering teams using Conductor Cloud should preserve a readable record of unfinished agent work before migrating their workspaces. Conductor's November 4 announcement says Cloud becomes read-only on November 13 and closes on November 20, when deletion of Cloud user data begins. The immediate governance task is to make sure another engineer can explain and continue each active change after the hosted workspace is gone.
The announced transition
Conductor says it is joining Meta. Its November 4 changelog confirms the Cloud dates and says local Conductor will receive new models and critical bug fixes until early 2027. SiliconANGLE independently reports the acquisition.
The company provides an option to transfer a workspace and its chats to a Mac, plus an account data export. These are announced migration routes, not proof that a particular team's history or working state has transferred completely. The checks below are Maetra recommendations for platform and engineering owners. They do not describe a tested migration or a guaranteed Conductor export format.
Assign a destination and an owner
Start with the workspaces that contain an active change, an unresolved review or information needed to reconstruct a release decision. Give each one an engineering owner. Record whether the intended destination is a local workspace, an internal archive or another approved development environment.
A download alone does not establish who is responsible for the work. The receiving owner should know which branch is current, which proposed changes are accepted and which agent suggestions remain unreviewed. Where several agents contributed, preserve the relationship between the workspaces and the relevant repository changes rather than treating the last chat as the entire history.
Use a compact handoff record: workspace identifier, repository, branch, current commit, unfinished changes, related pull request, receiving owner and archive location. Mark fields that cannot be recovered. An explicit unknown gives a reviewer a reason to investigate; an inferred identifier can create false confidence about where a change came from.
Preserve the explanation around the code
A repository commit may preserve the code while losing the reasoning needed to review it. For each material unfinished change, retain the task the agent was given, relevant constraints, the proposed modification and the human review state. Capture the test evidence that already exists and distinguish it from a claim in a chat that tests passed.
Do not keep everything indiscriminately. Chats and local working files can include sensitive material. Apply your organization's access and retention rules to the archive, and make the archive location visible to the people who need it. Restricting access should not depend on somebody remembering which laptop received a download.
Avoid copying live credentials into a narrative handoff document. If the destination needs access to a repository or service, arrange that through the approved credential mechanism and record the responsible identity. The record should explain the dependency without exposing the secret itself.
Verify one transfer before scaling the migration
Choose one representative workspace and use the vendor's documented transfer or export route. Then have the receiving engineer inspect the resulting state. Maetra recommends checking these points before treating that workspace as handed over:
- The expected repository and branch are present, with the intended starting commit.
- Uncommitted changes and untracked files have been accounted for where relevant.
- The receiving engineer can locate the task context and distinguish reviewed work from suggestions.
- Existing test evidence can be found, and any rerun is recorded as a new result.
- Links to pull requests, issues and the responsible owner still make sense outside the original workspace.
These checks deliberately avoid assuming what the export includes. If an item is absent, recover it through an available supported route or record the gap and decide whether the affected change needs another review. A transfer that opens successfully can still leave an important part of the work unexplained.
Keep the source available while the receiving owner checks the handoff. Since Cloud becomes read-only before it closes, plan your internal acceptance date early enough to resolve problems. The service dates come from Conductor; any earlier internal deadline is your team's migration choice.
Close the old access path deliberately
After a workspace has an accepted destination, review the access paths associated with the retired environment. Identify the relevant repository connections, service identities and locally stored configuration. Decide which remain needed for ongoing work and which can be removed through normal administration.
Do not assume the acquisition itself changes a customer's permissions or proves that access has ended. Likewise, a company's stated data-deletion schedule does not prove that your organization has met its own retention requirements. Keep a record of the decisions your team actually made and the verification it completed.
Maetra's AI audit evidence guide helps identify the history worth preserving. Audit supports inspectable change history, while Discover supports agent and capability inventory. Neither is a Conductor migration service or a promise to recover deleted workspaces. Use the Maetra documentation to plan a small evidence handoff that remains understandable after the original tool retires.