Migrate Off CoConstruct Without Losing Job History

Will I lose my job history when I migrate off CoConstruct?

Yes, unless you personally save it first, because the migration was never designed to carry it. This is not a warning about worst cases. It is what the two documents that actually govern the move say in writing, and neither of them is the migration page you have been reading.

The CoConstruct migration page tells you that no project data will be lost and that you will have access to CoConstruct in order to see historical project information. Both statements are true and both are narrower than they sound. Nothing is deleted out from under you during the migration window. Your history simply stays where it is, in an account you will eventually stop paying for, and the clock on that account is set by a contract clause rather than by the reassurance on the page.

The builder who started the most useful thread on this in r/Contractor put the shape of the problem precisely: "the switch itself isn't what keeps me up at night. it's the migration." He runs four to eight jobs as estimator, project manager and salesperson at once, and what worried him was not learning new software. It was "losing years of signed docs, selections, change orders, job photos."

He is right to worry, and the fix is not a better migration consultant. It is doing one specific job yourself, in a specific order, before your subscription lapses.

What does the Buildertrend migration team actually move?

Buildertrend publishes the answer as a help article called Data Entry Timelines and Approval Guideline, and almost nobody writing about this migration cites it. It opens by stating that Buildertrend Data Entry Services will not upload data that involves excessive manual detail, liability concerns, incorrect file format, and so on, then lists approved and declined services line by line.

Here is the part that decides whether your history survives.

Read the Not Included column as a single sentence and the picture is unambiguous. Templates move. Contacts move. Cost codes and the cost catalog move. Open jobs move as shells with a schedule, an estimate and a selections structure. The history of what happened, what it cost, who agreed to it and when, does not move, and closed jobs are excluded twice, once in the job transfer row and again in the job details row.

Why does the migration team refuse to enter my invoices?

Because it is a liability question, and the guideline says so in those words. Client invoices for jobs "will not be entered" and are annotated "(liability issue)". Job-specific purchase order pricing is declined with the note that "prices must be zeroed out as it is a liability issue". Lien waiver involvement is refused outright. So is entering or editing any communications with customers or vendors.

This is worth understanding rather than fighting, because it tells you what the service is. A data entry specialist keying a dollar figure into an invoice on a live job creates a document your client may act on and your lender may rely on. No vendor is going to accept that exposure for a migration ticket, and escalating does not change it. The same logic shows up at JobTread, whose published migration policy says jobs themselves can be imported but that migrating the data inside jobs, naming budgets, documents, daily logs, is a premium service at $25 an hour, and that if accessing your data requires signing into an external system, its team is unable to do that on your behalf.

That last sentence is the whole game. Nobody logs into your CoConstruct account for you. Whatever comes out of it comes out under your own login, on your own time, before the account goes quiet.

How long do I really keep access to my CoConstruct history?

One year after your subscription term ends, and even that is discretionary. This is the single most important fact in the migration and it is not on any migration page.

Buildertrend's Terms and Conditions Agreement, last updated June 24, 2026, addresses it at section 14.2, Access to Customer Data. The clause reads: "Upon expiration or termination of the Subscription Term, Customer's access to the Service, including Customer Data, will end. Customer Data may remain accessible for one (1) year after the Subscription Term's expiration or termination (the 'Post-Termination Access Period'). Customer may request access to Customer Data, and Buildertrend will determine, in its sole discretion, the format, method, and manner in which any Customer Data is made available. Such access, if provided, may be subject to applicable fees. After the Post-Termination Access Period, Buildertrend may permanently delete Customer Data in Buildertrend's sole discretion."

It then adds, for the avoidance of doubt, that "Buildertrend has no obligation to maintain or provide Customer Data after the expiration or termination of Subscription Period."

Four things follow from those sentences, in order of how much they should change your plan.

1. "May remain accessible" is not "will remain accessible." The permissive verb is doing real work. Plan as though the access is a courtesy, because the contract frames it as one.
2. The format is Buildertrend's choice, not yours. A post-termination export could arrive as something you cannot load into your new system, and the clause gives you no standing to ask for CSV.
3. It may cost money. "Subject to applicable fees" is explicit.
4. The clock starts at the subscription term's end, not at your migration. Which means your renewal date, not the 2027 deadlines, is the date that matters.

Section 1.7 defines Customer Data broadly enough that this covers everything you care about: name and contact details, subcontractor details, "location data and all associated job information, messages, attachments, files, tasks, to-do's, daily logs, invoices, purchase history, photographs, videos, plans, blueprints, drawings, specifications." That is your job history, named item by item, inside the clause that gives it a one year shelf life.

Can I just script a bulk download of my files?

Technically yes, contractually no, and this is where the best advice on the internet quietly puts you offside.

The most upvoted practical answer in that r/Contractor thread is genuinely good engineering. Open a job's documents page with browser developer tools on the Network tab, find the request that returns the file list, and you have every file ID mapped to its job. Download them in a loop overnight on your own logged-in session. No password sharing, no third party touching the account. Our own guide to exporting data from a CRM walks through the same three-layer mechanic in detail.

Now read section 2.3 of the terms. Clause (i) prohibits the customer from using "any software, devices, scripts, crawlers, robots, or other automated processes to copy, scrape, or systematically acquire any content contained within the Solution without the express written consent of Buildertrend." Clause (c) separately prohibits attempting to gain unauthorized access to the Solution or related systems.

Your own data, your own login, and still a clause that covers the method. Note the escape hatch built into the clause itself: written consent. That is the move.

Three routes that do not require you to weigh a breach:

• Ask for written consent, in writing, while you are a paying customer. Say plainly that you intend to run an automated download of your own files under your own credentials for archival purposes, and ask for confirmation. Either you get consent, which costs you one email, or you get a refusal that tells you to plan for the manual route.
• Ask support for a full export before you give notice. Some vendors produce a dump they do not advertise on any pricing page. The worst outcome is a no, and the request costs nothing while your account is healthy and paid.
• Pay an assistant for the clicking. Twenty hours against a checklist you write is cheap compared to your own hour as estimator and salesperson, and it is unambiguously permitted.

What should I actually archive from each closed job?

Six artifacts per job, and not the live thread. The instinct is to preserve everything, and it is the instinct that costs builders weeks and still ends up half wrong.

One consultant in that thread framed the tradeoff exactly right: "The switch is a weekend, the data is the year." Another was blunter about the attempt: every owner he has seen try to move years of selections and change order threads into a new platform "lost weeks and still ended up with half of it wrong."

So draw a date line. Closed jobs become a read-only archive on your own drive. Active jobs get rebuilt by hand. New jobs start clean in the destination. For the archive, these six:

1. The signed contract or accepted proposal. The document that defines scope and price. Print to PDF with the signature block visible.
2. The approved selections sheet. Not the selections tool, the approved state of it. This is a screen, not a file, so it only leaves as a PDF you print yourself.
3. Every signed change order. Each one with its approval date and the client's acceptance. This is the single most litigated artifact in residential construction.
4. The final invoice and its payment record. Remember that the migration team explicitly declines to duplicate payment information linked to client invoices, so the only copy that will exist is the one you save.
5. The photo set. Especially anything showing a wall cavity, a subgrade condition or a pre-existing defect. These are files, so they come out through the file route, not the print route.
6. Permits and inspection sign-offs. Worth calling out because the Buildertrend guideline notes that permit number and lot info are not included in a job details import, and are only added manually for batches of 20 jobs or fewer.

Everything else, the comment threads, the to-do history, the daily-by-daily schedule churn, is context you will almost certainly never open again. The exception is trade-specific: if you build in a jurisdiction where delay claims are common, or you run cost-plus work where the client audits, your daily logs are the contemporaneous record and they are explicitly in the Not Included column. Export them deliberately or accept losing them.

How do I do this without stalling four to eight live jobs?

Overlap, and pay for both platforms while you do. The double subscription is the actual cost of switching, and it is far cheaper than a week of chaos across every live job. We break the arithmetic down in what it costs to switch CRM, and the realistic timeline for a field service software switch covers why the calendar is longer than the work.

A sequence that works for a four to eight job shop:

One builder on that thread ran the overlap for six months while still using CoConstruct, and described it as the thing that made the switch manageable. That is the upper end, but nothing about the timeline rewards speed. The only step with a hard deadline is the archive pull, and its deadline is your renewal date.

What do I need in writing before I commit?

Six questions, and the answers belong in email, not on a call. This is the same discipline as our CRM data migration checklist, applied to one specific vendor relationship.

• Which items from the data entry guideline will you run for my account, and on what timeline? Name the rows. Job transfer, template transfer, cost catalog, cost codes, customer contacts, job details.
• Confirm in writing that closed jobs, daily logs and non-estimate financials are excluded. You already know the answer. You want it attributable.
• What is my post-migration price, and what is my renewal date? Buildertrend's migration notices, as summarized by JobTread in July 2026, put the entry-level annual project volume price at $699 per month, which is a floor rather than a quote. Section 4.3 auto-renews at then-current fees with a CPI increase of up to ten percent unless quoted otherwise in writing.
• How long will my CoConstruct account remain readable, measured from what date? Ask them to state it against section 14.2, because a verbal "indefinitely" and a contractual one year are not the same promise.
• Will you provide written consent for an automated export of my own data? One email. Either answer moves you forward.
• If I go elsewhere, what export formats are available while I am still a paying customer? Ask this before you decide, not after.

If you are still deciding where to land rather than how to get there, our rundown of CoConstruct alternatives and the 2027 exit calendar covers the destinations and the backward timeline.

The bottom line

The migration off CoConstruct is not risky because the software is hard. It is risky because two documents, neither of them the page you were pointed at, quietly define what survives.

The Data Entry Timelines and Approval Guideline tells you that your templates and contacts are coming and your job history is not, and that liability, not effort, is the reason for most of the refusals. Section 14.2 of the terms tells you that the historical account you were told to rely on has a one year shelf life measured from your subscription's end, in a format of Buildertrend's choosing, possibly for a fee.

Neither fact is hidden. Both are published. And both mean the same thing for your Saturday: the only copy of your job history that you can count on in three years is the one sitting on your own drive, in a folder per job, with a manifest beside it. Pull it while the account is paid and healthy, keep six documents per closed job, rebuild only what is live, and let the rest stay where it is until the clock runs out on it.