You may have made WinSCP working in some environment already, but you have failed to make it work in the new environment, be it new machine, new version of Windows, different user (or system) account, different network or combination of thereof.
There may be numerous reasons for this, some of which, including solutions, follow.
Configuration of WinSCP in the new environment may differ. Term configuration here does not include only preferences, but also sites and caches for accepted SSH host keys and TLS/SSL certificates.
Note that even when you are running WinSCP on the same machine as before, just under a different account (including different system account, such as when using Scheduler, SSIS, etc), you may not have the same configuration. By default WinSCP uses account-specific hive of registry to store its configuration, which is not accessible by other accounts. You may want to use INI file instead to ease configuration sharing.
Learn how to transfer your existing configuration to the new environment in general.
Particularly when using scripting you should avoid depending on configuration, where possible. Prefer configuring your session completely using
open command, using session URL (and raw sesssion settings, if needed), instead of storing site. Also always specify fingerprint of expected host key or certificate explicitly, instead of depending on caches. Good practice is to develop your scripts with configuration isolated from GUI.
If you are not able to find what differs between environments, turn on session logging in both of them and compare the logs. It should become obvious. Even if you give up and decide to seek support, make sure you post both complete logs.
You may want to check these more specific articles:
If you are having problems conecting and you are sure your configuration is exactly the same in the new environment, it may be worth checking if your connection is not blocked by a firewall.
See article dealing with firewall issues.
Site design by Black Gate