Userform from 32bit to 64bit

64-bit processors process code faster than 32-bit chips. They process 64 bits in parallel as compared to only 32 bits. The code is identical. It's like transporting water through a big pipe or one with smaller diameter. It makes no difference to the water.

Therefore, if your code doesn't run as expected the reason would be the change from one version of Excel to another. However, Excel provides backward compatability and I'm not aware of any particular problems between Excel 2013 and Excel 365. Run your code, see where it gets stuck and take the issue from there. It should be simple.

Another approach would be based on the fact that the number of bits processed depend upon the processor, not the application. Your PC wouldn't suddenly get a new processor by your changing the version of Excel you use on it. Excel 2013 and 365 both work with either class of processors. Find out how many bits your computer processes and adjust your setup of Excel 365 to match that capability.

Edit 15 Jan 2020  =============================

Based on the further information you have provided in the discussion below your code seems to contain APIs. These - more components of Windows than of Excel that they are - have been modified to adapt to the use of numbers of LongPtr datatype. LongPtr is a datatype that can take much larger numbers than the traditional Long, which are needed to address the much larger memories in newer computers. LongPtr isn't therefore, strictly speaking, related to 64-bit processors but to the advent of larger memories that came together with the ability to process data faster. On the sly, meaning unnoticed by most, VB6 was replaced with VB7 at the same time and that made all the changes work.

Now two versions of many APIs exist. One uses Long, the other LongPtr. One runs on 32-bit machines, the other on 64-bit ones. The version using LongPtr is identified by the key word PtrSafe. They introduced the system constant VBA7 enabling programmatic differentiation in VBA7. You can now write code that runs on both systems. Here is an example.

#If VBA7 Then
    Private Declare PtrSafe Function SetCurrentDirectory Lib "kernel32" _
        Alias "SetCurrentDirectoryA" (ByVal lpPathName As String) As Long
#Else
    Private Declare Function SetCurrentDirectory Lib "kernel32" _
        Alias "SetCurrentDirectoryA" (ByVal lpPathName As String) As Long
#End If

Use the #If VBA7 evaluator in exactly the same place where you have the API function (meaning outside a procedure) and then keep both versions in your code. The compiler will select the correct one.

You can google for the API your code needs. You already have the old version of it. Look for how to write its PtrSafe equivalent. You can use one #IF VBA7 to declare several APIs.