The MBR isn't the issue. Leaving aside things that install themselves as MBR computer viruses, such as GRUB, proper conventional MBRs have little to be affected by differences between machines. The principal thing that varies from machine to machine that affects how the bootstrap code in MBRs operate is the presence of the Phoenix/IBM/Microsoft INT 13h extensions. Some MBR bootstrap programs simply assume that the extensions are always present. Its absence isn't really a concern for machines manufactured in this century, since most retail PC firmwares shipped since the middle to late 1990s have these extensions, so your concerns about the MBR are largely a red herring.
The more appropriate focus of concern is addressed in the answer to the question that was pointed out by shlck above. The device drivers employed by your operating system, as configured and installed in a system volume on the disc, may be completely wrong for the new machine.
For Windows NT, for example, the HAL and the "boot start" class drivers must be the right ones to enable the system to come up on the new hardware. (This is the Windows NT version 6.x boot process.) Microsoft already provides Microsoft KnowledgeBase article #249694 detailing many of the factors that will stop this from being the case; so I won't repeat them here.
The same concerns apply to other operating systems. For Linux, as another example, Carla Schroder notes that you can be faced with "typically cryptic and unhelpful" error messages if the compiled kernel being bootstrapped and (as M. Schroder doesn't explicitly state but as Andryan Prakasa Gouw notes) all of the initrd modules don't properly match the new hardware.
