What is the best way to migrate recurring tasks without duplicating future work?

Start with an inventory. For each recurring task, note its title, recurrence pattern, next expected date, whether the rule is active or stopped, and any visible future instances. Keep completed tasks separate from upcoming ones.

Google Tasks’ export documentation says its export includes recurrence details and schedules, task IDs, due dates, completed timestamps, stopped status, and whether a task is an active recurrence instance. That can help you audit the source records; it does not establish that another app will import those fields or deduplicate them. [S1]

Choose a comparison window, such as the next 30 days, and record the expected instances in it. This gives you a manageable way to check that future work appears once.

Test a small sample first. In the destination, inspect the repeat settings and dated tasks separately. Ask: Is there an ongoing rule? Which future dates appear? Does completing one occurrence create another, or are future occurrences already listed?

Don’t infer the result from a successful-looking import. Microsoft Planner’s documented behavior varies by experience: in the described current experience, only the current occurrence is displayed and the next scheduled task is created when it is completed; each occurrence is a separate task. The article describes different behavior in the previous experience. This explains Planner behavior, not how another app imports its data. [S2]

For example, compare a short date window in both apps. If the source shows a rule and Monday and Tuesday instances, check whether the destination has the rule, those dates, or both. Use a test item or preview rather than completing a real task just to check recurrence.

Compare records by meaning, not just by title. Use a combination of title, due date, status, and source task ID when available. Check that every expected future date appears once, stopped rules have not become active, and completed items have not reappeared as open work.

For example, suppose “Submit weekly report” is due every Friday and the source shows the next two Fridays as future instances. If the destination has a repeating rule and two separately scheduled Friday tasks, check whether completing the first task will generate another. Decide which representation to keep before the schedule runs. This is a hypothetical example; behavior depends on the destination app.

Planner’s Excel export is described as a snapshot of plan tasks at export time, including task IDs, titles, statuses, and due dates. Its documentation does not list recurrence rules or explain importing the spreadsheet into another app. Treat it as a record-checking aid, not proof that schedules transferred. [S3]

Use a staged handoff:

1. Record the source rules, statuses, and future instances, then export.
2. Test a small sample in the destination; check both recurrence settings and dated tasks.
3. Fix missing or duplicated entries before moving the rest.
4. Choose one app to own each active schedule during the handoff. Avoid keeping the same active rule in both unless you intend to have both generate reminders.
5. Keep the old schedule available until you have checked the destination’s upcoming dates and how it creates later occurrences. Then stop updating the old schedule rather than deleting source records before verification.

You can track each item with: Task: [name] | Rule: [pattern or unknown] | Next due: [date] | Instances checked through: [date] | Source ID: [ID or unavailable] | Destination rule checked: [yes/no] | Duplicate review: [pass/fix]

Exact import behavior depends on the apps involved; there is no cross-app procedure established by the documentation cited here.