u2lcapw.dll is a 32-bit Crystal Reports UFL (User Function Library), so it can't be used in Crystal 2020 (64-bit).

Good chance your report is using the PwFormatDate() function to convert YYYYMMDD integer values into Date values.
If you wish to stay with 64-bit Crystal, you can replace the function call with formula logic. For example:

local numbervar YourNumberDate := 20231020;

cDate(Val(ToText(YourNumberDate,0,'')[1 to 4]), 
      Val(ToText(YourNumberDate,0,'')[5 to 6]), 
      Val(ToText(YourNumberDate,0,'')[7 to 8]));

Alternatively, there is at least one 3rd-party Crystal Reports UFL (with 32-bit as well as 64-bit versions) that provides such a function.
Ken hamady maintains a listing of 3rd-party Crystal Reports UFLs here.  

u2lcapw.dll is a 32-bit Crystal Reports UFL (User Function Library), so it can't be used in Crystal 2020 (64-bit).

Good chance your report is using the PwFormatDate() function to convert YYYYMMDD integer values into Date values.
If you wish to stay with 64-bit Crystal, you can replace the function call with formula logic. For example:

local numbervar YourNumberDate := 20231020;

cDate(Val(ToText(YourNumberDate,0,'')[1 to 4]), 
      Val(ToText(YourNumberDate,0,'')[5 to 6]), 
      Val(ToText(YourNumberDate,0,'')[7 to 8]));

Alternatively, there is at least one 3rd-party Crystal Reports UFL (with 32-bit as well as 64-bit versions) that provides such a function.
Ken hamady maintains a listing of 3rd-party Crystal Reports UFLs here.  

There is no point in using 64-bit Crystal.  It's not faster, it's not better, and Sage uses a 32-bit runtime engine.

Thanks for this. That's a nice resource, but I think it's just a better idea to switch back to 32bit.