text: user131: Is working with and relying on old genome builds still valid?
  For example NCBI36/hg18. Would results from papers based on old builds require LiftOver and re-analysis to be useful?
  A bit of context, this is related to other post, where we have aCGH results based on old build: How do I validate a single sample ArrayCGH result?
  
  user383: You could use liftOver which isn't always great.
  Whenever I encounter this (especially NGS data readily available on the SRA), I often just get the raw files (e.g. fastqs) and re-align/re-map.
  In your case (arrays) it may be a bit tough. Not impossible though, as I recently took some old yeast DNA/RNA microarray data and updated it to the newest genome. Just requires the right data (like DNA for normalization) and a good understanding of the entire process.
  A last resort/alternative is to align your new data to the old genome to be able to make comparisons. This isn't ideal but works in cases where upgrading one source isn't possible or is a HUGE amount of time/effort. I've done this for a few fly experiments where all the available/previous data was done in dm3. All the old genomes can generally be found on http://archive.ensembl.org .
  
  user247: I think that right now, the only human builds that are worth considering are hg19/GRCh37 as many data bases such as gnomAD still exclusively use this release. On the other hand, hg38/GRCh8 has many important fixes and the useful (but yet underused) feature of alternative loci.
  Anything from older releases should be remapped to a more recent one.
  
  user425: In my opinion, it is not very reliable. LiftOver is very limited in terms of transformations it can support. The LiftOver Chain format can capture only matching regions in the same order. It means that it can account for indels, but even simple structural variations become problematic.
  For instance, when a newer assembly is available, it is usually a recommended practice to remap all the reads rather than transform the existing alignments.
  
original_text: 131: <p>Is working with and relying on old genome builds still valid?</p>
  
  <p>For example <a href="https://genome-euro.ucsc.edu/cgi-bin/hgGateway?db=hg18&amp;redirect=manual&amp;source=genome.ucsc.edu" rel="nofollow noreferrer">NCBI36/hg18</a>. Would results from papers based on old builds require <a href="https://genome.ucsc.edu/cgi-bin/hgLiftOver" rel="nofollow noreferrer">LiftOver</a> and re-analysis to be useful?</p>
  
  <p>A bit of context, this is related to other post, where we have aCGH results based on old build: <a href="https://bioinformatics.stackexchange.com/q/316/131">How do I validate a single sample ArrayCGH result?</a></p>
   383: <p>You could use liftOver which isn't always great.</p>
  
  <p>Whenever I encounter this (especially NGS data readily available on the SRA), I often just get the raw files (e.g. fastqs) and re-align/re-map.</p>
  
  <p>In your case (arrays) it may be a bit tough. Not impossible though, as I recently took some old yeast DNA/RNA microarray data and updated it to the newest genome. Just requires the right data (like DNA for normalization) and a good understanding of the entire process.</p>
  
  <p>A last resort/alternative is to align your <strong>new</strong> data to the old genome to be able to make comparisons. This isn't ideal but works in cases where upgrading one source isn't possible or is a HUGE amount of time/effort. I've done this for a few fly experiments where all the available/previous data was done in dm3. All the old genomes can generally be found on <a href="http://archive.ensembl.org" rel="nofollow noreferrer">http://archive.ensembl.org</a> .</p>
   247: <p>I think that right now, the only human builds that are worth considering are hg19/GRCh37 as many data bases such as gnomAD still exclusively use this release. On the other hand, hg38/GRCh8 has many important fixes and the useful (but yet underused) feature of alternative loci.</p>
  
  <p>Anything from older releases should be remapped to a more recent one.</p>
   425: <p>In my opinion, it is not very reliable. LiftOver is very limited in terms of transformations it can support. The <a href="https://genome.ucsc.edu/goldenpath/help/chain.html" rel="nofollow noreferrer">LiftOver Chain format</a> can capture only matching regions in the same order. It means that it can account for indels, but even simple structural variations become problematic.</p>
  
  <p>For instance, when a newer assembly is available, it is usually a recommended practice to remap all the reads rather than transform the existing alignments.</p>
  