SDR的**手操作运营经验2005至2008年间，SDR的开发及操作经验对于SDR2.0的要求及设计具有指导性作用。当关于数字存储功能的确切性质及需求等问题还没有解决的时候，RLGDDDNARA2007就明确提出了支持大规模数字存储服务的首要目标：根据数据格式、内容结构或知识背景等转化而来的新的学术资源必须能够经过简单分析及开发就可被轻松获取、处理。系统必须能够容纳大规模的集合，而不论集合规模大小及数量多少。管理功能不仅支持有标准需求的常规工作，还支持有独特需求的鉴定及管理工作。存储及检索程序必须简单灵活，并足以支持各个方面的工作。
物理瓶颈：计算周期、带宽、存储SDR的原始设计把获取模型架构与转化、存储与存取模型架构按优先顺序进行了明显的区分，经验证明在宏进程中进一步细化功能能够提高可访问人数的吞吐量及管理能力。例如：原来的设计是作为一个连续的管道而运行获取功能，重新设计后把它分解成了多个独立的功能（如注册、校验、打包、复制、核查等），每个功能既可在并行的实例中运行，也可被异步调用。SDR目前配置的第二个物理瓶颈是它的磁带存储子系统。当大型客体以可接受的吞吐量在三个存储管理器上管理磁带副本的写入或复制时，由于缓存高于为每个客体建立单独的链接，从而对于大量小型客体的获取速度就降到了令人无法接受的程度。明显的解决办法就是在获取时把大量的小型客体“集装箱化”成较少的大型客体。更灵活及更系统性的接入就是SDR2.0的需求，然而，SDR2.0的设计格外重视引入完全存储抽取及管理服务，在存储层把变化及操作功能从SDR的高级功能中隔离出来，优化不同子系统（磁盘、磁带或云为基础的）吞吐量。
逻辑瓶颈：数据建模及转化分析SDR的原始数据模型为了提交信息使用了元数据编码及传输标准（METS），并对其做了轻微的修改，也使用了元数据编码及传输标准作为存档及传播信息包的基础。SDR强调对类似交叉目标类型的管理及技术元数据部分的重复利用，这种状况下的传输设计必须要有大量的数据分析做后盾。有时需要为新的内容类型写入复杂的打包脚本，而它代表了采用新格式时的一个重要瓶颈。SDR也尽可能地为传入集合保存元数据。在预期优化有待于建造的总体发掘系统和传输系统时，尝试用一种标准方式在各个不同集合之间捕获并架构描述性元数据；同时不摒弃它们之间任何一个细微的差别。总体来说，这可以说是一个“万无一失”的方法，针对每一种新的内容类型及集合都要求做大量的详细分析从而创建出一个详细而恰当的转换单。而*终的经验表明：这种方法对于每种内容的数据流来说是不可持续的。很明显，保存服务的多样化及内容规模要求数据流要具有持续性，SDR需要把它的内容建模策略转化成更“及时”的方法，从而为获取准备集合。