looking at it, to me it appears that it is slow because you are looking at a LOT of data to review and then update a single row. Mind you that is all ESTIMATED, not actual.
It appears you have no FK constraints set up (guessing here based on what you posted), but those function calls on your JOINs are really hurting performance as you are turning that into a row based operation which you can see on the execution plan:
Estimated Number of Executions
Estimated Number of Rows
it is running that one at a time for a total of 108576 for one of the 2 tables where you are using functions in the join. The other tables in the JOIN appear to be suspicious too as they are only estimating 1-2 rows coming back.
My GUESS is that SQL is guessing wrong and coming up with bad estimates which is resulting in tempdb spill and possibly other issues causing slowness. Could be blocking as well causing the slowness. I would try your query on a test system and let it run to completion (capturing the actual execution plan) so you can see:
A - the actual plan
B - the actual execution time on a mostly unused system
Something that MAY help (may not) is pulling the data out of the tables into temp tables or table variables rather than relying on NOLOCK which can give bad results (missing or duplicate). NOLOCK MAY be the appropriate answer to your specific use case and I am not recommending removing it, just might want to evaluate other options.
You also appear to be using cross-database queries which I've seen cause performance issues. You may benefit from having all of the data on the same database. What I mean is you could clone the tables from Z2urlSystem to extractreports that you need to do that update on and then use the tables in extractreports and remove the cross database queries.
A statistics update may help as well.
Just some things you can try; I would test some things on a test/dev environment and move to live once you have determined why it is slow and corrected the issue. I would start by getting it running on test so you can see an actual execution plan even if it means waiting 10 hours for it to complete. At least then you can see the estimated vs actual execution plans to determine if statistics is an issue which is a "quick win" in most cases.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!