I think the key thing here is to always use relative paths in your blend files when linking external data. That means for linked libraries, textures and any other data external to the file.
Relative paths are mostly guaranteed to work if you maintain the folder structure relative to the blender file intact, even if the absolute paths are changed.
That means if you move your files to a different machine or even on your own current machine but maintain their positions relative to each other things should not break.
Whereas absolute paths are never guaranteed to work in a different machine, unless you can recreate the exact same base path for everything down to the same drive letter.
They are also likely to break in different operating systems, like say you send a file to someone else on a different platform, not even if you change operating systems in the same computer, because for example Windows uses drive letters to locate different volumes, a concept that doesn't exist in Unix based systems, because volumes are mounted to mount points instead.
The good news is I think Blender already does this by default, so in theory you should not have to do anything, unless your store stuff across different drives letters, cross link from network data, or specifically set Blender to use absolute paths.
You can double check this by opening one of the files in question, going to the Outliner and changing the menu in the header to Blender File this should list all local data stored inside the current Blender file, and bellow it towards the end of the list all loaded external data from other .blends. From there you can check which files are loaded and from where.
If a path looks something like //..\Path\to\my\Library.blend
or //.\Textures\ then is relative and all is good. If it looks something like D:\Path\to\my\Library.blend
(has a drive letter in it) than it is likely to break in the new computer.
You can easily fix this by going File > External Data > Make all paths relative, if all external files are in the same volume as the blend file.
Blender has relatively good asset management capabilities, in the new computer you can then check if anything is missing by going to File > External Data > Report missing files
Now make sure that when you move stuff you maintain the same internal folder structure. One good way to organize your projects would be:
📁Master Folder
├ 📁Blender Projects Folder (for throwaway projects that you may archive at some point when finished)
│ ├ 📁Project 01
│ ├ 📁Project 02
│ ├ 📁Project 03
│ └ 📁Project ...
│
└ 📁Library folder (For reusable assets and library files you may keep around indefinitely)
├ 📁Models
├ 📁Animations
├ 📁Textures
├ 📁Materials
└ 📁...
Independently of where in the file system you place the Master Folder
, if you maintain the underlying internal folder structure intact, and all files reference each other using relative paths within this "garden" all should be fine.
One additional rule I've been enforcing on all my projects for increased resilience besides this, is to make sure each individual project is also fully self-contained and entirely kept inside a single dedicated project folder, with no external dependencies, even in the Libraries folder.
This means making a local private copy of any assets used just for exclusive use of each project at the expense of disk space. This may cost extra storage in the long run, but it means I can safely move each project individually elsewhere without fears of breaking dependencies, like say archiving when finished, or sending to someone else.
This also makes projects resistant to future changes. If you need to open it at a later time, somewhere in the far future, it has been kept safe from any breaking changes (like updates, upgrades, evolutions or other modifications) that might have happened to libraries in the meantime, which could jeopardize the fidelity of the project that has been stagnant.