I ran across this paper recently which conveys it better than I can:
"[refactoring], defined traditionally as a set of program transformations intended to improve
the system design while preserving the behavior. Refactoring studies are expanded beyond code-level restructuring to be applied at
different levels (architecture, model, requirements, etc.), adopted in many domains beyond the object-oriented paradigm (cloud
computing, mobile, web, etc.), used in industrial settings and considered objectives beyond improving the design to include other
non-functional requirements (e.g., improve performance, security, etc.)." [1]
I've been having a lot of thoughts lately that we should stop calling things 'refactoring'. There is no incentive to do refactoring for anyone other than a developer (users don't want it, PM do not want it, QA do not want it, peer Dev's do not want to review it). Instead, we should probably be more direct in the language, "this was an update to existing module X so that it would be consistent with the updates in module Y. The two modules were previously consistent, this is an update to maintain consistency." Rather than "Refactored module X". That latter phrasing invites the very leading question: "you are working on Y, why did you touch X?"
At the end of the day, the ideas, tools & techniques are useful, the vocabulary can get in the way. (I am guilty of letting that vocabulary get in the way. At the same time, it is troubling. How are we to share ideas without the starting point of a shared vocabulary?)
If you change the code without changing the functionality, it's a refactoring.
If you change the main organization of the code, it's re-architecturing.
It being one of those has no impact on whether it's also the other.