Main and visibly apparent difference between n-tier and clean architecture

Disclaimer. I'm not looking for a discussion or opinions of those two. Nor do I aim at evaluating or describing them. I'm in a project where I'm supposed to set up a path to refactor from the traditional to the domain driven one and I wish to keep the changes as small as possible still achieving the task.

According to MS docs for clean architecture, the onion shaped diagram is supposed to differ from the n-tier architecture, which is layer shaped.

It all makes sense while reading but then, a different view of the clean architecture is presented and it looks quite similar to the n-tier architecture. Of course, I do understand that those differ but trying to understand the core point on where and how they differ doesn't get easier by that resemblance.

An even better example of my the reason for my uncertainty is this blog. It's not .NET related but architecture ought to be technologically agnostic. As far I understand, the actual path of the process is layer based and precisely equivalent to n-tier version (only differing in how it's drawn, which should be irrelevant).

Is the main difference between those two architecture types simply how we're using them or is there an actual difference code-wise or in the project structure (except for the naming, of course)?

As far I understand, the actual path of the process is layer based and precisely equivalent to n-tier version (only differing in how it's drawn, which should be irrelevant).

Yes, that's right.

Is the main difference between those two architecture types simply how we're using them or is there an actual difference code-wise or in the project structure (except for the naming, of course)?

The difference is which code knows about, has references to, depends on other code.

In N-Tier, the business logic needs to know the API of the infrastructure layer. All of the dependencies point down.

In clean architecture/onion architecture, etc, the infrastructure layer knows about the API of the domain layer. All of the dependencies point inward.

Clean architecture puts the business logic and application model at the center of the application. Instead of having business logic depend on data access or other infrastructure concerns, this dependency is inverted: infrastructure and implementation details depend on the Application Core.

This style is often accompanied by the use of a Composition Root, which is responsible for wiring together the components that will eventually do the work.

Are you saying that there's no business logic layer in onion version? I.e. that it's baked in into the application core?

Typically, business logic is understood to be in the middle of the onion. For instance, Robert Martin offers

You may find that you need more than just these four. There’s no rule that says you must always have just these four. However, The Dependency Rule always applies. Source code dependencies always point inwards.