The process of migrating from Sass to native CSS

👨 Chris Smith

📅 Aug 19, 2026 📖 4 min read

For years Sass offered us superpowers. It was a superset of CSS, opening up a world of possibilities for developers. The ability to use variables, functions and nest our rules was too good to turn down.

Today we have all of this in native CSS. It caught up. So, unless you're doing something very particular, Sass just isn't needed anymore.

The why

Whilst you'd probably not consider bringing Sass into any new project now, it's also not really doing any harm in your long standing projects. As it all gets compiled to CSS at build time, it never gets near the browser, so you'll never have to worry about security issues like you might with some other ageing technologies.

Whilst not a problem, I took the decision to replace all our Sass with native CSS as I could see some benefits.

Having a mixture of CSS custom properties and Sass variables was confusing and meant duplicating code
Where the .scss file was outputting a .css file, it's an extra file to maintain, copy on deployment, etc.
Our build is (ever so slightly) faster
We can get rid of the compiler package dependency
One less thing for developers to learn

The how

It's not a complicated process but there are a few gotchas if you don't consider all the things that can go wrong, so I'll list some steps to keep it smooth. You can use AI for this or do it manually. Either way, hopefully this will help.

1. Find the Sass

Identify all your .scss files. This can be with AI or a simple Find operation. You just need a list to work through.

2. Find any Sass sass

Search for any Sass specific features, like mixins or named functions like lighten(), anything that wouldn't just work in native CSS. You'll need to replace these with CSS functions or just use their compiled values copied from the existing generated CSS files.

3. Check for Sass comments

Search for any comments that use the // syntax. This is supported in Sass but not native CSS. You'll need to swap it out for /* ... */ syntax. If you miss this step then any rules following a comment won't get parsed.

4. Remove generated CSS

Remove any CSS files that were generated by the Sass compiler. Be careful not to accidentally delete any CSS files that we hand written in CSS if you've been mixing and matching the technologies. Also remove any generated minified files or map files so you're left with only the files that you edit.

5. Rename files

Rename your .scss files with the .css extension. As you've stripped out any Sass only features you should be left with working CSS files.

6. Update references

Find all references to .scss files, e.g. <link rel="stylesheet" href="forms.scss"> or styleUrl: modal.scss. Update these to use the .css versions.

7. .NET specific

If using .net, check that your project file has the correct items listed within <Content>. This controls which files get copied on deployment. If you have lingering .scss files or missing .css files you'll hit problems.

8. Build

Rebuild everything and check you're error free. Hopefully any mismatched references will get caught here.

9. Test

If you have any automated tests run them. Importantly, check your pages manually. One missing CSS rule can fail silently and even be quite subtle to spot so allow time for checking everything thoroughly. The more eyes you can get on this the better.

10. Remove the compiler

If you use a package or extension to compile Sass to CSS you can now remove it.

11. Remove Sass related config

You may possibly have config somewhere that tells your compiler what to convert, where to put the output, etc. This can be removed too. I'd suggest doing a search for '.scss' and seeing if there are any remnants that you can finally remove.

Imports

One nice feature of Sass is the way it can import other Sass partials allowing you to keep your styling in lots of small files, e.g. _forms.scss, _tables.scss, _typography.scss but they all compile into one big CSS file, e.g. global.css. The browser gets one bigger file, one request.

When moving to native CSS only we can't do this any more. We can use imports but they are now at runtime so trigger a secondary request in the browser. Whilst this does not take long it does mean the 2 requests have to run sequentially, which is not ideal.

A better approach is just to have lots of small files. Since HTTP\2 the number of requests is not a limitation and having lots of small requests running in parallel is actually faster than one long one. So, rather than import what were your partials, add them into your page or template as separate requests.

<link rel="stylesheet" href="forms.css">
<link rel="stylesheet" href="tables.css">
<link rel="stylesheet" href="typography.css">

If you have changed how imports or bundling happens, it's worth testing the performance and seeing if things have got better or worse. You may need to consider bundling files server side, using minification or delaying non critical CSS files to improve your page load time.

Good luck!