The German radar imaging spacecraft TerraSAR-X was launched in June 2007. It is operated from the German Space Operations Center (GSOC) in Oberpfaffenhofen. The mission has a partly commercial character and very high orbit-control requirements. Very fast access into the downloaded house-keeping data is required in order to fully judge the health and correct status of the spacecraft, but also for calibration purposes of the acquired image products. To be able to react to a potential anomaly the operations engineers need to have full access to the offline data within 40 minutes after the dump, since the next pass is often after only 80 minutes. Since up to 11 hours of data can be accumulated in a single dump, this poses a high demand on the offline system performance. With the new TanDEM-X spacecraft which will be launched in October 2009, the requirements for high-performant offline data processing and fast data access are even higher. It turned out that the original offline processing system development met the performance requirements well, but had other drawbacks in computing accuracy, configurability and maintenance. Thus it was decided to refine the requirement definitions and re-develop the offline data processing system. The system presented runs as one control process including graphical GUI to survey the processing. The operation is completely encapsuled in virtual machines; thus the specific configuration needs only once to be configured and can then be saved in a dedicated virtual machine. It is thus also possible to move the software to other hardware or operation system. The natively supported platforms are WinXP and Linux (up to SLES10). Distibuted computing is possible via a control process. The processing is straight forward, i.e. all products are generated based on a generic product format which is highly configurable by content, name etc. Various processor configurations are possible, actually one to four data processors supported to use QuadCore platforms are the optimum. Direct demultiplexing of input data streams is possible (e.g. VCs, SPIDs, APIDs...). Native leap second handling is possible via database, that means leap seconds need only once to be configured and the system allows easy reprocessing of old data without the necessity to change configuration for leap seconds. Further there is no necessity to split data which span over leap second jumps.