Cycles Blog
How to Migrate Recurring Tasks Into a Rotation Planner
A four-step checklist for moving recurring tasks from a to-do app into a rotation planner without losing recurrence rules or momentum.
How to Switch to a Rotation Planner Without Losing Your Rules
Deciding to switch to a rotation planner takes a minute. Moving the recurring work inside your to-do app takes a plan. Three things reliably go wrong during a recurring task system migration: recurrence rules change silently in transit, dead tasks get imported by default, and momentum evaporates into weeks of double entry.
The fix is a four-step, tool-agnostic checklist: export and inventory, prune, translate into rotation cadences, validate in week one. Done in that order, the move takes about a week. It is also reversible by design, because exporting deletes nothing in the source tool. The old system can be paused rather than deleted, which changes the psychology of the whole project: you are running an experiment, not burning a bridge.
Why to-do lists break down for recurring work
Due-date systems fail recurring work by turning it into an ever-growing overdue list. When you miss a weekly task, the failure carries forward; next week arrives carrying last week's weight. Over months, the list stops describing what matters and starts describing what you didn't do.
A rotation planner answers a different question: not "what's late?" but "what deserves attention next, within the capacity I actually have?" Instead of one-size-fits-all recurrence, it offers three modes: strict for fixed timing, weighted for uneven importance, shuffled for chronically neglected work. If the concept is new, the introduction to rotation planners covers when the model helps and when it doesn't.
That reframing is why migration is worth the effort. This is the rare moment when you can migrate recurring tasks into a better model instead of copying the old one into new software.
Step 1: Export recurring tasks from Todoist without losing the rules
Start with an inventory, not an export. Isolate repeating items in the source tool first so you know the size of the move. In Todoist, type "recurring" into search, or build a filter view like "recurring & today" to surface every repeating item in one place.
Todoist offers four export paths: per-project CSV, whole-account ZIP backup (Pro and Business plans only), the Google Sheets export, and the API. None is a complete copy of the account, so pick paths based on what you need rather than looking for a single "export everything" button (Donebear's export guide maps the gaps). The per-project CSV excludes completed tasks entirely, and the Google Sheets export includes them but drops labels, deadlines, comments, attachments, and reminders.
Plan on two exports: one carrying task detail, one carrying completion history. Auditing what actually got done requires a different file than the rules themselves.
The detail export has one silent trap. As Todoist's documentation puts it, "the start date of a recurring date isn't saved in the CSV file." A task set to "every year starting January 31" exports as plain "every year." The task still recurs, but on a schedule that no longer records when it began. The change survives import and only surfaces later, when the task fires on the wrong day.
One more practical note. If you are following an older migration tutorial, know that Todoist's Sync v9 and REST v2 API endpoints were retired in early 2026.
Step 2: The pruning pass
A rotation planner is capacity-first, which makes migration the ideal pruning moment. Never import everything by default. For each recurring task, ask the question that matters: does this recur because it matters, or because it was set once in 2022 and never revisited?
Use four explicit criteria:
- Last completed date. Open the completion-history export (Google Sheets or API) and compare what actually happened against what was planned.
- Skipped rate. A task you defer every single cycle is telling you something.
- Emotional weight. Tasks that generate guilt without generating results are candidates for removal, not tighter scheduling. Every rotation also deserves a stop rule; this piece on stop rules for recurring tasks is a useful companion here.
- Whether anyone would notice if it stopped. If the honest answer is no, let it go.
Prune before translating. There is no reason to design a cadence for a task that won't survive the audit, and a rotation planner that runs fewer, fairer rotations beats one that reproduces a longer overdue list. Pruning is burnout prevention, not just tidying.
Step 3: The translation table
This is the step that changes the model rather than the address. Map each surviving task's due-date pattern onto one of the three rotation modes:
Current pattern (example task) | Recurrence behavior in the old tool | Rotation mode |
|---|---|---|
"Every Saturday" (trash day, invoicing) | Fixed-day: always reschedules to the next Saturday, completion date irrelevant | Strict |
"Every week" (tidying, client check-ins) | Dynamic: reschedules from the last completion, so the weekday drifts | Weighted, once intent is confirmed |
Frequent-vs-rare pairs (deep cleaning vs. tidying, key clients vs. minor admin) | Importance is uneven; a due date treats them as equals | Weighted |
Chronically skipped six-month or yearly items (home upkeep, creative practice, self-care) | The point is fairness, not a specific date | Shuffled |
Before you map anything, decode the old tool's recurrence behavior, because picking the wrong one breaks the migrated cadence. In Todoist, "every Saturday" (fixed-day) always reschedules to the next Saturday regardless of when you completed it; "every week" (dynamic) reschedules from the day you completed it, so the weekday drifts; "every! 3 days" (completion-based) counts from the moment you mark it done. Dynamic recurrence is the most common cause of recurring tasks repeating on the wrong day, per Todoist's recurring-dates guide. When you translate, capture the intent behind the rule, not just its text.
When you have dozens of items, cluster them by frequency and time investment: a weekly block, a monthly block, a periodic block, each with its own cadence. That grouping keeps a bulk import from becoming one undifferentiated pile. This is also the point where the mapping should click into place in Cycles, where strict, weighted, and shuffled are first-class modes rather than workarounds.
Import the rule, not the history
Migrate the recurrence definition and drop the overdue backlog. Every rotation starts at zero debt.
This is the single most important rule of the move. Due-date systems carry failure forward; a rotation planner doesn't have to, so don't import the failure. Overdue counts and streak history from the old system encode your old capacity, not your current capacity, and importing them quietly rebuilds the overdue-list dynamic you left to escape. Keep the export file for reference. Let the rotations themselves start clean.
Running both systems in parallel without double entry
Momentum dies when you log completions twice. Three habits prevent that.
First, keep the old app installed for a month as a safety net, since exporting deletes nothing in the source tool. Pause its recurring tasks, or move them out of view, so nothing fires reminders twice. Pause; don't delete.
Second, name one system of record on day one. New recurring tasks enter the rotation planner only, and the old tool becomes read-only. A firm cutover date, set in advance, keeps the safety net from becoming a second brain.
Third, lean on the local-first architecture. Cycles keeps your data on your device, so there is no account deletion to regret, no server round-trips for planning decisions, and no vendor lock-in to undo. If you ever move on, the export you keep is the rollback path. One caveat for anyone comparing destinations: cross-tool imports, such as into TickTick, often have to be done manually, a gap the TickTick versus rotation planner comparison covers in detail. That is one more reason to keep the move small.
Step 4: The one-week validation checklist
- Hand-verify every recurring task. Non-negotiable, because CSV exports silently drop start dates. A rule that says "every year" may have meant "every year starting January 31."
- Confirm each cadence fires as intended. Strict tasks land on their fixed days, weighted tasks appear in the right proportions, shuffled tasks actually rotate fairly rather than clinging to one item.
- Watch the first days for double reminders from the paused old tool.
- Run the momentum test. Is the planner returning a realistic next step within your capacity, or are you rebuilding an overdue list under a new name?
- Re-run the pruning criteria. Anything skipped repeatedly in week one probably didn't earn a rotation slot.
- Keep the archived export as the rollback path, then archive the old app once the week passes.
A short, reversible move
The whole migration in one line: export and inventory, prune, translate into rotation cadences, validate in week one. Reversible by design: exports delete nothing, the old app stays paused rather than deleted, and local-first data stays on your device. The payoff is recurring work that stops becoming overdue debt and becomes fair, capacity-aware rotation. If you are ready to see how Cycles works, the rotation modes are the place to start.