Five years after delivery, the customer calls. The machine is moving to a different hall, an adjustment shaft got damaged, and could you dig up "the data from back then". The engineer who built it has moved on, the project folder holds thousands of files, and nobody knows which PDF was really the last one. What should have been a ten minute phone call becomes an afternoon of archaeology.
Moments like that reveal whether a project was ever truly closed. Because a project is only finished when its dataset is: final exports captured, clutter cleared out, metadata complete and the whole thing frozen, so nobody accidentally keeps working in it. This article gives you a concrete closing checklist and answers what to keep and why. And if you want to close and archive a CAD project properly, a toolbox like Thundercad turns most of it into batch work instead of click work.
Why closing down always loses out
The day the machine leaves the building, the next project is already pushing. Planning rewards whoever moves on quickly, not whoever spends another half day on a finished job. So the dataset stays behind in working state: stray export folders from interim deliveries, iProperties that were correct halfway through the project, scratch models for a variant that never happened.
For months, nobody notices. Until a service technician has to go out, the customer reorders a wear part, or a discussion starts about what exactly was delivered. Suddenly the question "what was the final state?" costs hours, and those hours appear in no budget anywhere. Closing down properly is not administrative fussiness, it is risk control: you record what was delivered at the moment everyone still remembers it.
The closing checklist
Closing becomes manageable once you follow a fixed sequence. Run through this list per project, right after the last delivery:
- Check the release status. Is every drawing at the delivered revision, with nothing left hanging in draft?
- Complete the metadata. Project number, description, material and revision filled in on every part, including the rush changes from the final week.
- Clear out the clutter. Scratch models, rejected variants and outdated work exports go in the bin, or into a folder that is very obviously not the archive. How to deal with those old export files is covered in Cleaning up old exports, so production never builds from revision A.
- Run the final export set. Every drawing to PDF, the sheet metal to DXF, the model to STEP: the as-built set.
- Put the set in the agreed place. One archive structure, identical for every project.
- Freeze everything. Read-only, an archive state or a locked folder: pick one mechanism and use it every time.
- Record where it lives. One short note per project: which revisions were delivered, where the export set sits and who closed the project.
What you keep: native files plus neutral formats
Keep both, because they answer different questions. The native Inventor files are the only form you can truly continue from later: derive a variant, push through a change, retrace a calculation. But native files depend on a complete CAD environment: libraries, templates and a working Inventor installation. For the question "what did we deliver?" you want formats anyone can open, including a buyer or a fitter without a CAD seat.
That makes the neutral set at least as important: a PDF of every drawing, DXF of the sheet metal, STEP of the model. With Batch Publish from Thundercad you create that set in one go: select the assembly and the tool publishes all underlying drawings in bulk to PDF, DWG, DXF and STEP, working together with Vault along the way. With Export Folder, those files land straight in the fixed archive structure, so the set looks the same for every project.
Curious how much of your closing checklist could be batch work? Run the as-built export set of a finished project with your own data.
Try 30 days freeThe as-built export set earns itself back in service
The biggest return on a clean close comes in the years after delivery. A customer reordering a wear part wants a price today, not a search party. With a complete as-built set you open the part's PDF, check the revision and pass the request on to purchasing or production, without opening old models or rebuilding an old CAD environment.
The same goes for service visits: a technician carrying the right drawing solves more on site than one who has to call the office. And if you play it smart, closing down is also the moment to lay the groundwork for a wear and spare parts list. How to build one from your Inventor data is covered in Service and spare parts lists, straight from your Inventor data.
Frozen means frozen: prevent silent changes
The most treacherous risk to an archive is a colleague working in it with good intentions. Someone uses the delivered machine as the starting point for a new order, changes three parts and saves. From that moment the archive no longer matches what is standing at the customer, and you only find out at the next service call.
So make continuing impossible, or at least awkward: set files to read-only, use an archive state in Vault, or move closed projects to a location where the department has no write access. And agree on one rule: a new variant always starts as a copy under a new project or order number, never inside the original folder. The archive is a snapshot of what was delivered; everything that happens afterwards is a new project.
Frequently asked questions
How long should you keep a closed project?
The practical answer: as long as the machine can be standing at a customer, which is usually longer than any formal retention period. Storage costs next to nothing compared with reconstructing a lost dataset. So keep the complete project, native files plus the neutral export set, rather than a trimmed selection you hope will be enough.
What if something changes after handover?
Treat it as a normal revision: implement, release, then rerun the as-built export set for the affected parts. The archive should always reflect the state at the customer. A half-updated archive is more dangerous than no archive at all, because everyone trusts it.
Does closing down properly not cost too much time next to the next project?
As an assumption, count on half a day per project when exports and metadata are batch work; by hand it takes a multiple of that. To see what it means for your own projects, simply try the export steps on a finished project with the free trial month of Thundercad.