Software: Your tests will not produce useful information if you are running vastly-different software or configurations on the low-end and high-end boxes - performance improvements (and sometimes, with the addition of new features, detriments) can be expected with software releases. Consider the difference in CPU time if one machine were configured to, for example, GZIP HTTP responses and the other were not.
Hardware: In order to get useful information from your tests, (depending upon the goal of testing) you will at least need to have a similar hardware configuration. Stress-testing is intended to reveal bottlenecks - typically, web servers bottleneck on CPU time and disk I/O (particularly if there is not sufficient RAM capacity and the system relies upon swap).
Low-end hardware can approximate the performance of high-end hardware, but differences in things like CPU speed, available RAM, and RAID configuration or disk read/write speed may create bottlenecks on a low-end machine in a different order of appearance than a high-end machine would demonstrate.
If your goal is to identify application-level performance improvements, testing beforehand (even on a low-end system) is an excellent decision: knowing how your application impacts the system it runs on will allow you to make informed decisions about how your application is configured (or which features - e.g. caching - are needed to support increased load) and what to watch for on your production system.
If your goal is to obtain a realistic picture of the load your production system will support, you will want to duplicate the exact setup you will be using in production to ensure that the expectations set by your testing reflect the reality of your production system's capabilities.
