If someone forked it in github, or have a copy at home or in gitlab, even press the history button in github, they can continue using the old licence for the old code, and "fork" the project and modify it using the old licence.
You change the licencee only for the future code.
Beware that changing it to MIT means that tomorrow Amazon can launch a hosted version and earn millions and not send you a dime. I like MIT and I'm not worried about Amazon for my projects, but many people don't understand this side effect.
On making it known when you no longer control the repo: publish a dated statement that names exactly what it covers — ideally the commit SHA of the tree you're relicensing, since the surviving fork's history gives you a stable identifier even though you don't own it. Sign it if you can, then open an issue on the fork pointing at it. The downstream question is "can I rely on this?", and a signed statement naming a SHA answers that in a way a README edit doesn't.
One thing that surprised me building tooling in this area: the relicense will not propagate to anything automated. If the project was ever published to a package registry, the license metadata on those releases is fixed — registries record what was declared at publish time. A scanner resolving a pinned version will keep reporting GPL-3.0, correctly, and whoever ran it has no way to know a statement exists. If people are going to depend on the revived project, cutting a new release under the new license is what actually makes it visible downstream.