Keep What The Board Does Well
Trello is good at showing state. Lists show stages, cards show tasks, and drag-and-drop gives a team a quick shared view. Atlassian's Trello 101 describes that board, list, and card model clearly.
Cards can also hold descriptions, comments, labels, attachments, and dates. The problem is not that Trello cannot hold context. The problem appears when several cards, comments, and linked documents can all look authoritative.
A person may reconstruct that picture from memory. An AI agent needs explicit sources, permissions, and stopping rules. This migration is therefore not a card export. It is a controlled change in ownership.
The destination works like a library with one departures board. Files give each fact one home. The queue alone announces what moves next. This extends the same idea behind turning finished projects into reusable knowledge.
Steps
Guide
Preserve The Board Before Changing It
Export what your Trello plan permits, then create a migration inventory. Record the board, list, card title, status, member, dates, attachments, links, and any decision buried in comments.
All board members can export raw JSON. CSV board export depends on a Premium Workspace. Atlassian also states that a board JSON export contains the 1,000 most recent actions, including comments. Read the current Trello export guidance before treating an export as complete history.
Include useful archived items and record linked documents separately. The output is a reconciliation list: every useful item must later map to an owner file, an archive reference, or an explicit decision to discard it.
Separate Finite Projects From Standing Areas
A project has a finite outcome. It can finish and move into an archive. An area is a standing responsibility that continues, such as publishing, reporting, or website operations. How to Structure AI Projects With PARA covers the full folder model.
Boards often mix both. A recurring rule can sit beside a one-off task. A permanent checklist can live inside a temporary card. Separate them before creating the new structure.
Give each area a thin instructions file. State what belongs there, which sources the agent may read, which files it may change, and which actions still require a human. Put finite work into specifications that can close.
Keep the router thin. It should point to facts, not duplicate them. OpenAI's guidance on keeping repository instructions contextual and current supports the same practical rule.
Give Every Fact Exactly One Owner
For every useful card detail, ask: which file is allowed to own this fact? Use a small set of answers.
- The queue owns scheduling status.
- A specification owns the agreed change.
- An instructions file owns standing rules and permissions.
- A decision log owns the date, choice, and reason.
- A reference file owns stable source material.
If another file needs the same fact, link to the owner. Do not paste a second authoritative copy. Copying every card into a new file preserves the old ambiguity in a new format.
Record decisions separately from discussion. A useful entry says what was decided, when, why, and which work it affects. Link to evidence when the conversation matters, but do not make an agent reconstruct the decision from comments.
Let One Queue Alone Schedule Work
Create one queue with a small, fixed status vocabulary. For example:
queued,in_progress,blocked,completed, andarchived.The exact words matter less than the rule: the queue's status field is the only place allowed to schedule the next action. Specifications describe work but do not keep a second next-step list. Meeting notes may propose work but do not activate it.
I run n-g.be this way. One roadmap file holds every website change, and its status column is the only thing that schedules a nightly agent. Each row links to one specification file, and a decision log sits beside both. The roadmap schedules. The specification explains. The decision log preserves why.
The agent matches status words literally. A status written as free text matches nothing, so the row is silently skipped. Keep the vocabulary short, document it above the queue, and treat any other word as an error.
Replace The Board Behaviours You Still Need
Moving away from Trello removes useful interactions. Name each loss before cutover and replace it deliberately.
- Visual board: generate a view from the canonical queue.
- Drag-and-drop: write a controlled status change back to the queue.
- Shared manager view: filter the same queue by status, owner, or date.
- Card comments: keep discussion in a collaboration tool, then record the final decision in the decision log.
Many views are fine. Only one source may own the state. A generated board can remain familiar without becoming another manually maintained queue.
This is where AI becomes infrastructure rather than decoration. AI Is Not Magic. It's Infrastructure. explains the broader operating principle.
Run One Complete Work Cycle
Do not migrate every board at once. Run one complete task through the new structure. Ask a human and the agent to find the next eligible task, its specification, the owner of each important fact, the reason behind a key decision, and the point where human approval is required.
Then reconcile the migration inventory. Every active card must map to an owner file, an archive reference, or an explicit discard decision. Check attachments and linked documents separately.
Do not judge the structure only by whether the agent produced an answer. Check whether that answer can be traced to the correct source, and whether a human can correct the source without hunting through copies.
When the project structure is stable, Codex Technical Setup is a useful next step for configuring the agent itself.
Archive The Old Board After Reconciliation
Once the work cycle passes, stop using Trello as an active queue. Keep the board available as history under your access and retention rules.
Archive instead of deleting during migration. Atlassian states that archived cards remain retrievable while deletion is permanent. Reconcile, archive, observe, and make any later retention decision deliberately.
A read-only historical board is useful. A second live queue recreates the problem. Set a clear cutover point and tell every participant which system now schedules work.
Be Aware
Every card became a file, but authority is still duplicated.
Assign each fact to one owner file. Replace every other authoritative copy with a link.
The team still keeps next steps in personal notes or specifications.
Move every schedulable action into the canonical queue and remove status authority from other files.
The new system lost the manager's visual overview.
Generate a board or table from the canonical queue. Do not maintain the view as a second source.
The agent can read the project but its permissions are unclear.
Add explicit read, write, approval, and stop rules to the relevant area instructions file.
The old board and new queue are both still active.
Complete reconciliation, announce the cutover, and archive or make the old board read-only.
Trello Migration Handoff
Copy / paste
Migrate one active Trello board into an AI-readable project.
Before changing anything:
- preserve or export the board
- list cards, archived items, attachments, links, and decisions in comments
- confirm the private destination and human approver
- do not delete or reorganise the source board during inventory
Create:
- one canonical queue with a fixed status vocabulary
- one specification per finite change
- one thin instructions file per standing area
- one decision log with date, decision, reason, and affected work
- one migration record mapping each source item to its owner or archive
Rules:
- every fact has exactly one owner file
- other files link to the owner instead of copying the fact
- only the queue status schedules work
- the agent may not invent missing decisions or permissions
- sending, publishing, deleting, paying, or approving stays with the human unless explicitly authorised
Validation:
- run one complete work cycle
- trace the task from queue to specification to decision history
- confirm a human can correct the owning source
- archive or make the old board read-only only after reconciliation passes
