As you may have found out it depends on the specific system where this can be applied. If AES-256 is supported then the algorithmic overhead is usually limited; it would possibly only be a problem when it comes to embedded devices.
As also mentioned, key management is probably the biggest hurdle. Re-establishing keys can be really hard. It can also be very simple; e.g. you could simply reconfigure the cipher suites of TLS, and since the (ephemeral) symmetric session keys are established during the handshake, you would probably not even notice the change. However, if the keys have been pre-distributed then replacing the keys from a trusted source maybe costly, possibly prohibitively so.
For hardware: there are certainly embedded CPU's systems that only support AES-128 hardware acceleration. Due to the puny CPU's it may not be feasible to run AES in software. In that case AES-256 is probably a no go. Most modern CPU's in PC's support AES acceleration for both key sizes on the other hand.
For protocols: AES-256 uses 32 byte keys. This can be an issue if a your key derivation mechanism only outputs smaller amounts of bytes (say PBKDF1 with SHA-1), or is inefficient (say PBKDF2 with SHA-1) if you retrieve too many bytes from it. On the other hand, the block size of AES-128 and AES-256 so if the block cipher is seen as a black box, then the input / output (plaintext / ciphertext) requirements won't change.
Similarly, if you have a large disk that is encrypted with AES-128 then re-encrypting it using AES-256 then you may have to wait a long time before the process is finished, not so much because of AES but because of the I/O.
So without further information: it depends, it can be a single configuration string or it may not even be possible and everything in between...