> The point is that previously, changing code in a major way might take months of refactoring.

> Now, the kinds of changes that were simply unrealistic before are now entirely realistic. A refactor/migration that would have taken 6 months before, you can now get a working version done in a day, and another few days of QA.

Significantly changing a system implementation is a function of understanding, not time.

Given a starting solution state being A and a desired functionality state of A', the tooling used to codify the A -> A` delta is largely irrelevant. Specifically, in order to successfully deliver major product realignment requires awareness of what exists currently and understanding of what needs to be.

Code is neither stone nor clay.

  When making software, remember that it is a snapshot of
  your understanding of the problem.  It states to all,
  including your future-self, your approach, clarity, and
  appropriateness of the solution for the problem at hand.

  Choose your statements wisely.

This is fantasy though.

The reason code takes time to change is not because changing it takes time.

You have to redo all the testing and relearn all the hard fought and underspecified lessons of the previous attempt. That's what takes the time.

I was watching the most recent Rich Hickey talk[0] and at the start, he talks about correctness and the difference between the internal machinery of your software (which can be finely specified) and handling the external world (which will always be messy).

Good Architecture will try to isolate the two. You got the internal logic which is either the business domain abstracted away. And you got the highly volatile part (request from frontend, new integration, new drivers, deps update,....).

If you've done that, migration/refactoring, unless it entails some unlikely core changes, will not take that long. It's just a matter of dropping that part and replacing it (like changing a car's brake pads or steering wheel). But the actual core mechanism will hardly change over the years.

To go with the thread flow: It's a stone core wrapped by clay.

[0]: https://www.youtube.com/watch?v=P5eO7BNyJao

ADDENDUM

In regards to separation, one of the best example in mind is the OpenBSD kernel code. The OS concepts are in /kern, while each architecture lives in /arch. There's an horizontal separation between machine independent code (core idea of Unix) and machine dependent code (The hardware platform). It can also be found in the various subsystem like audio (the concept of a sound card) and implementation like uaudio (usb interface) and azalia (Intel's HD Audio).