Blog - HubsGrowth

How to Clone a Project With Tasks and Subtasks in HubSpot

Written by Yaryna Bil | Jul 21, 2026 7:50:22 PM

If you run recurring work in HubSpot Projects - client onboarding, campaign launches, implementation plans, event prep - you know the drill. A new project kicks off, and somebody digs up the last one just to see what was on it, then rebuilds the task list by hand, half from memory, half from a doc that's probably out of date.

Here's the short version: cloning a project with its tasks and subtasks intact is possible. HubSpot just doesn't do it natively. That's what CloneNer is for. Before getting into how it works, it's worth understanding why the gap exists in the first place - because it's not a small one.

When you clone a project in HubSpot, you get a new project with a name and a due date. That's it. Everything that actually made the original project useful - the tasks, who owned them, how they were sequenced - stays behind.

For a one -off project, that's a shrug. For a team running the same kind of project every week, it's a small tax that never stops getting collected.

What HubSpot's native cloning actually copies

Worth being precise here: cloning a project in HubSpot duplicates the project record - its properties, its pipeline stage, its associated fields. Not the tasks sitting on it. This isn't a rumor or a one -off complaint; it shows up repeatedly in HubSpot's own community forum, where people trying to build project templates keep hitting the same wall. HubSpot's own team has confirmed it's a gap they're aware of, not a deliberate design choice.

It actually goes one layer deeper than that. There's no native way to clone, bulk copy, or import/export tasks in HubSpot at all, project or no project. The workaround is a workflow that auto - creates tasks, which needs a Professional or Enterprise seat and still means building and maintaining automation just to reproduce a checklist you already had.

Why the tasks are the part actually worth keeping

A project record on its own is mostly a shell. What makes it useful is everything underneath - the order tasks happen in, the subtasks nested inside them, who's on the hook for each one, and how due dates cascade off the kickoff date.

Lose all of that on clone, and someone has to rebuild it by hand every time. On a five-task project, fine, mildly annoying. On a 25 - or 30 -task onboarding sequence, it's real work - and every manual rebuild is a chance for a task to get skipped, an owner to go unassigned, a subtask to just quietly not exist.

Where this actually shows up

A few situations where full project cloning - tasks, subtasks, and all - makes a real difference:

Client onboarding. A services team running the same onboarding sequence for every new client benefits most obviously. A 25 -step project split across phases, each task owned by a specific person, should look identical the first time and the fiftieth time. Clone the full structure and it does, without anyone retyping the checklist.

Recurring campaigns. Marketing teams running a similar campaign every month or quarter - creative, approvals, scheduling, reporting - can duplicate the whole task breakdown instead of rebuilding it each cycle. The campaign changes. The process underneath it doesn't need to.

Scheduled internal work. Quarterly audits, renewal reviews, compliance checklists - anything on a fixed cadence benefits from a clone that already has every step in place, instead of relying on whoever remembers the full list from last time.

Projects with several owners. When subtasks are split across a few people, keeping those assignments intact on a clone means the team's responsibilities are set the second the project exists. Nobody has to ask who's doing what.

The thread running through all four: if a project is really a template - something meant to run again and again, not just once - the tasks and subtasks need to come with it. Otherwise the template isn't actually in HubSpot. It's in a doc somewhere, or in whoever's run the process the most times, getting copy -pasted in after the fact.

What changes once tasks clone with the project

Time saved is the obvious part. But a few other things shift too, once the whole structure clones automatically instead of just the shell:

  • Every project starts from the same complete structure, so nothing gets left off because someone forgot a step mid -rebuild.
  • Someone running a project type for the first time inherits a finished task list instead of needing a walkthrough of what should be on it.
  • The process lives in the project itself, not in the head of whoever's run it the most.
  • Owners and due -date logic carry over, so accountability doesn't reset with every new project.

If you're running a handful of projects a year, this is nice to have. If you're running the same type at volume - five onboardings a week, a dozen campaigns a quarter - it adds up fast. It's the difference between a tool that stores a name and a due date, and one that actually holds the process.

How CloneNer closes the gap

This is the exact problem CloneNer was built for. Where native cloning stops at the project record, CloneNer's Duplicate Project window lets you pick what travels with the clone - tasks, subtasks, and a set of related records beyond that.

From the same window, you can:

  • Set a new name, template, and pipeline stage for the clone, instead of cloning first and fixing it up after.
  • Choose exactly which tasks come over. Every task on the original project shows up as a checkbox, so you can clone all of them or just the ones that apply to the new project.
  • Bring related records along too - Notes, Meetings, Calls, Emails, Services, Courses, Listings, Appointments, and Time Logs are all optional properties on the same screen, each labeled with how many records exist on the original.
  • Keep the task list, subtasks, and assignments intact instead of starting from an empty project every time.

For a services team cloning a 25 -task onboarding project, that turns "rebuild the checklist" into "open Duplicate Project, confirm the tasks are selected, set the pipeline stage, clone." The subtasks, the owners, the structure - all of it comes along.

The takeaway

HubSpot's native cloning does what it's built to do: duplicate the project record. It stops there. CloneNer picks up from that point - letting teams clone the tasks, subtasks, and related records that actually make a project worth reusing, instead of handing back a name and a due date.

FAQ

Does HubSpot clone tasks when you clone a project?

No. Cloning a project in HubSpot duplicates the project record - its properties, pipeline stage, and associated fields, but leaves the tasks behind. The clone starts with an empty task list.

Does HubSpot clone subtasks?

No, for the same reason. Since tasks don't carry over on clone, the subtasks nested under them don't either.

Is there a native way to bulk-copy or import tasks in HubSpot?

Not currently. HubSpot doesn't offer a built-in option to clone, bulk-copy, or import/export tasks, whether or not they're attached to a project. The closest workaround is a workflow that auto-creates tasks, which requires a Professional or Enterprise seat.

Does the same limitation apply to cloning campaigns?

Yes. Cloning a campaign in HubSpot copies the campaign record but not the tasks tied to it.

How does CloneNer clone tasks and subtasks with a project?

CloneNer's Duplicate Project window lists every task on the original project as a checkbox, so you can select which ones to bring over. Subtasks and task owners clone along with the tasks you select.

Can CloneNer clone anything besides tasks?

Yes. The same Duplicate Project window includes Notes, Meetings, Calls, Emails, Services, Courses, Listings, Appointments, and Time Logs as optional properties, each showing how many records exist on the original project.

Can I change the name, template, or pipeline stage while cloning?

Yes. CloneNer's Duplicate Project window lets you set a new name, choose a template, and select a pipeline stage for the clone before creating it