End of Support changes in SketchUp 2024

We’re excited about SketchUp 2024. It’s been great to hear the positive feedback on new improvements like the Ambient Occlusion making models more realistic and easier to understand and the improvements to graphics that make it much easier to view and navigate big models. But that’s not what this blog post is about. This post provides more context for less popular changes we’ve been making to SketchUp based on our “End of Support” policy.

End of Support: What’s that?

All software (and hardware) eventually dies. Windows 95 was a great operating system, but it’s dead in terms of support from Microsoft even as Windows still flourishes. To ensure SketchUp does the same, we have to make decisions about when to stop supporting older versions.

To this end, we formalized our End of Support policy a couple of years ago. SketchUp’s End of Support policy is how we constrain the cost of maintenance. We do this by asking ourselves, “How much effort does it take us to continue to support an old version, and how much value do our paying customers get from that support?”.

The burden of ongoing support

For an example, let’s consider Add Location. In SketchUp 2024, Add Location got a reboot. The feature needed to be rebuilt on new technology so that it could be efficiently improved with new functionality in the future. We were not able to update Add Location on old SketchUp versions, so we will now have two versions of that feature live for customers to use. We will maintain these two Add Location versions until SketchUp 2023 goes out of service in January 2026. This means for the next two years, we are committed to doubling our investment in:

  • Security updates
  • Customer support, documentation, and training
  • Compatibility testing between versions

This extra cost is real and does not bring any value to customers. On the flip side, it forces us to invest in maintaining old code instead of investing those resources in fixing bugs and shipping new, high-quality features. The new version should be better and we should be able to just have everyone use it, but when it comes to desktop software, people don’t always want to and sometimes can’t update straight away. Introducing clarity around the End of Support policy has helped us a lot in planning, estimating, and controlling these costs.

Okay, but why restrict downsaving?

In SketchUp 2024.0, we have taken away the ability to downsave to versions of SketchUp older than 2021.

Including downsave capabilities in new versions adds cost and also constrains how we evolve file formats in the future. For example, if we included downsaving in 2024, we would task ourselves with doing QA (Quality Assurance) to make sure every file format works. We would try to fix bugs associated with failures in downsaving. If we spend R&D time on this, we have to take it away from other things people want.

Looking ahead, we would also need to think about whether new features would "break” downsaving and whether we should change designs or invest more effort in those features just to make sure we could keep downsaving to ancient versions. We don’t want our engineers worrying about that - we want them to be able to look forward and focus on capabilities that support customers with new technology.

This is why we have removed the downsave feature from 2024.0 and why we needed to start managing expectations better about downsaving in general.

In short - our focus is forward-looking. There are so many ways people want us to keep improving SketchUp. We’re prioritizing our development spend on addressing those needs.

Providing feedback

If you want to be part of the process of providing feedback on future development, check out our Labs page, where we share experimental projects we are seeking feedback on. We’d love to have you involved in our testing and development process - helping us make SketchUp a better product for you.

If you’re an existing user and this affects you directly, please tell us here. We’d like to understand your workflow and see if we can help make this easier.

Thanks for your time.


the short version :

a solution for 2024 users

another solution for any users (standalone)

In my reading - we currently have a “small transition period” - my above solution perhaps is only temporary, it works until the SketchUp staff removes it from the Ruby API as well. External solution - independent exporter, like above link - can be written further, if e.g. Suforyou decide so…


indeed. :slight_smile: I think your solution is good to have at hand right now for users who sometimes (or often) deal with classic users, but on the long run, their partners and clients switching to the subscription.
You’re giving us a “grace period”, allowing us to use 24 (who knows, 25?) and still collaborate with them.

su4u’s solution is a must-have for anyone still using a classic version, as it allows versionless files to be translated to 17-20 formats. And if people need older than 17, then there is always Make17.

For the past ten years, despite diligently paying every cent on time, I have not received any support from Trimble SketchUp but frustration.


I’m curious - if you’re using the current version, how is this affecting your workflow?

1 Like

I don’t know what to think of this change. I know very well why you’re doing this, but I think it’s a bad idea. It’s going to affect everyone, even those who, like many here, have always paid for their subscriptions or licenses.


I am very happy with my end-of-purchase policy since 2020.


1 Like

There’re some SketchUp issues but not important because I can use Ruby to adjust it. But LayOut is getting worse and worse in focusing to the documentation workflow.
LayOut was a revolutionary vision in UI and UX for architects to quit Autocad’s habit of making CAD documents. But now no more. They seem to back to copy and bring more and more old Autocad fogy features.
It’s incredibly frustrating that LayOut’s functionality for automation has regressed so drastically since version 24. The Ruby Console was at least somewhat helpful, albeit limited, for automating tasks within LayOut files - directly while it was opening (although without a UI, but still helps anyway). However, now even that seems insufficient. In older versions, like 2017, one could create a temporary adjusted layout file, compare it with the original, and then decide whether to save the changes. This was a valuable workflow that’s sorely missed.

Despite these issues persisting over the years, developers have failed to address them adequately. Problems such as non-ASCII font bugs, the absence of shortcuts or toolbars for table commands, poor entity and text movement previews, clunky dropdowns lacking search inputs, subpar autotext editor, and abysmal UI for inserting and managing Excel references continue to plague LayOut. It’s disheartening that these concerns seem to have been largely ignored by the development team. They are working like they never know how to use and what to use LayOut for.


Why does Autocad still let users save files to the R14 version (since 1997), but SketchUp cannot?


it strips out a lot of features, but yes its available.
maybe sketchup could do the same - export raw geometry to SKP but essentially “explode” almost everything.
People can’t expect to save as SKP2017 (or R14) and then re-open it in 2024 with all the 2024 features enabled and functioning properly.

in fact, most of the time, when someone complains that their DWG file opened at a wrong scale in sketchup, it’s because it’s likely an autocad 2000 file and the drawing unit isn’t in the header.
For some weird reason, people teaching autocad still tell their student that if they are giving a dwg for another software, autocad2000 is the safest format because everyone can read it.
in 2024.
meanwhile with their 3-4y file structure, any software released since 2018 should be able to open the most recent DWG2018 files.

Microsoft still supports “save as” to pretty much any format, even Word97 or RTF or WordPad. Same with Excel.

Yes, you may lose some information, and you are warned about it. But it’s doable. I suspect unfortunately that this is a move to get rid of all the 2017 Make users out there. And tremble could: just offer people to purchase something and own it. Even if the price is double of 1 year subscription.

I don’t understand - was there some function in 2017 that’s been removed that let you save a temp file? Or was there ruby scripting functionality in Layout that was removed? And why can’t you just do a save as to a different file to do your temporary work and then decide if you want to move forward with that file or the previous file?

I hear a lot of noise about this issue, but I’m not hearing many concrete workflows this actually affects. So far I’ve heard of one, and that was someone that was saving dynamic components into V6 files because it removed the dynamic functionality because they didn’t want to share proprietary dynamic models.

Beyond that, I’m not hearing many legit workflows that this affects. You can access all 3D Warehouse files in the free version, and download them as Collada files if you need them somewhere else, so this isn’t walling anyone out of the Warehouse.

I’m still looking for those use cases, so if you have something more specific, I’d love to hear it.


Lol - people seem to be expecting that in perpetuity :rofl:

Wouldn’t this basically be exporting to COLLADA? (Or STL or another format?)

it’s not a question of workflow.
It’s about being able to work with and work for people still using their classic licence.

  • last year, made some 3d models for an architect. He uses 2020.
  • Later, he needed some photorealistic images, the guy he uses has a 2018 licence.
  • in January, I trained a guy who frequents a fablab. the machines in the fablab runs Make2017
  • right now, a couple of architects (uni friends), working with their classic SU2015
  • February, taught a pair of woodworkers, he has a classic 2020, she has a classic 2019.

and while some of them are aware of their limitation and have dealt with it (the fablab aforementioned has su4u’s tool installed, same for the woodworkers), some won’t. they are paying me for a result and expect me to adapt to their situation.
that’s how it works in all the pro softwares out there, the more recent version can adapt to work with the older one.

If you need more cases, go to the original link

Gjohnson has customers still on 16 an 17
Push mentions plugins needing 2015 files and municipalities asking for 8 (not surprised on that one…)
Colin gave you the example of unity needing 2019.


Exactly ! That says it all.
In the end, @JustinTSE, you’re the one who makes the most noise :sweat_smile:

I asked a question, and I asked for clarification when I didn’t feel the answer answered the question I asked. If that’s “noise,”…sorry?

@ateliernab Gave several concrete examples of people this is going to affect, which I appreciate. I interact with students online all the time that are using older versions. I totally support that, and honestly wish the free version of SketchUp was still a desktop version as well.

I’ve been trying to figure out how many people this actually affects, but the whole conversation is likely moot anyway, as this seems to be the direction things are going.

1 Like

Surely (Shirley!) the decision is final and Trimble folks will not revert this decision, but nevertheless it is important that users provide feedback to the development and product management teams with their thoughts on such product changes. Personally I think that removing the ability save as older versions is a disappointment.

Part of the reason I chose in 2012 to use SketchUp for my non-professional (but rather serious) hobby project is that other people could access my free model using free desktop versions of SketchUp. Thus I make the model available in 2016 format (somewhat arbitrary choice), though I develop it using a later version. (My model is too complex for today’s free web-based SketchUp implementation to handle. I suppose in the future that will no longer be true, in which case the lack of saving to older versions will be less of a sting.)


Totally agree, and a lot of those impacts are significant to a lot of workflows. I do think it’s fair to also balance the fact that it does take up resources that could be used elsewhere to support those older versions.

It’s kind of a case by case basis, but I assume with ANY software company, you do have to weigh if supporting versions that were last purchased in 2014, 2015, etc is really a good use of resources that could be used on feature development, fixing issues in the newer version, etc. Especially if those cases seem to be the exception, not the rule.

I would assume this is this case - with the internet being the way it is, it’s probably better for me to just…exit the conversation, since it’s not going to change anything anyway.

This is the bummer to me - the web based version does have some significant performance downsides compared to the desktop version, and it also makes modeling with extensions out of reach for free users.