• Sales: 1-800-961-2888
  • Support: 1-800-961-4454

Slicehost Forum: Migration to Rackspace Cloud: Q&A with Mark Interrante and Rackspace - Thread Comments

CommentAuthor kohudson CommentTime May 4th 2011

I would like clarification on one point please. Will I be required to do a migration prior to May 2012?

Thank you, Ken

Thankful People: jkoenin

CommentAuthor HanchorLLC CommentTime May 4th 2011

By ‘downsizing’ does that mean that on the new system, you can’t change the size of an existing server or does it mean that you can increase but not decrease (i.e. the ability to increase capacity on a machine for a specific high traffic event goes away)?

CommentAuthor nickp CommentTime May 4th 2011

Thanks for posting this FAQ. It’s much more informative than the email sent out yesterday. However, I still have concerns.

The loss of IP addresses for slices at the STL-A and STL-B data centers is a MAJOR problem in your transition plans. I understand that IPs are provisioned to ISPs and data centers, but you need to find a way to make this happen for your your loyal customers. In the case of my company, we have over 250 domains pointing to our Slicehost IP address (where we host websites for lots of small businesses), so even though there will be a one-click transition for the server, there’s no such thing for all the DNS updates.

Would it be possible for Rackspace to set up some sort of proxy at the STL-A/STL-B data centers that would live on for an additional few months, allowing us Slicehost customers time to transition our DNS? There has to be a way for you to make this happen. Losing the IP addresses we’ve come to depend on isn’t an acceptable solution.

CommentAuthor lethe CommentTime May 4th 2011

Regarding switching nameservers, you say it can happen independently of my move to rackspace. Does that mean rackspace will host my DNS records before my slice is migrated to Rackspace? Do I currently have a Rackspace customer login?

CommentAuthor glibdud CommentTime May 4th 2011

Can we be provided with historical bandwidth data for our slices in order to get a better idea of what our costs are likely to be if we decide to use Rackspace?

CommentAuthor HanchorLLC CommentTime May 4th 2011

Having that bandwidth data would be a huge help. Right now, all I know is that I’ve never gone over my allotted amount here at SH…

But that’s worthless info - if I take my total allotted bandwidth and plug it into the RS calculator, it shows me paying 2x what I’m paying now… So I really have no idea if I need to start looking at alternatives or if RS is a viable option for me.

CommentAuthor dlrust CommentTime May 4th 2011 edited

Posted By: HanchorLLC

By ‘downsizing’ does that mean that on the new system, you can’t change the size of an existing server or does it mean that you can increase but not decrease (i.e. the ability to increase capacity on a machine for a specific high traffic event goes away)?

I also agree that downsizing is one of slicehost’s best features that should be maintained. like in the case where a certain server starts to have performance issues, the slice can be upgraded, optimized, and then downgraded to test

Thankful People: mattbeck

CommentAuthor mattbeck CommentTime May 4th 2011

The ability to do temporary size increases to handle a site getting slammed with traffic via groupon/fark/digg/whatever is important.

CommentAuthor wlashell CommentTime May 4th 2011

First, thank you for continuing to provide us with more information. This will help to ease concerns that RS is not paying attention to its customer base.

A sticking point for our transition is the necessity of transitioning all servers at once. We have 8 to 10 slices depending on the month with two slices hosting several ecommerce sites, as well as the other slices hosting 20 - 200 sites each. If we have to do all of the servers and sites at the same time it is going to be a very long day and night for our systems guys with no good way to make sure its all going to go perfectly.

It is still not quite ideal, but doing one server at a time is a lot nicer to those of use with a multiple ips and slices to deal with.



Thankful People: jwilhelm, mattbeck

CommentAuthor jimbattenberg CommentTime May 4th 2011 edited

Good questions all, thanks much. Here are the first few answers:

@kohudson: yes, you will be required to do a migration by May 2012 at the latest as we are migrating out of the STL-A and STL-B data centers

@HancorLLC, @dlrust, @mattbeck: you can increase ram/hd (scale up) a server, add servers (scale out) and delete servers (scale in), you will not be able to resize down. We understand this is a core feature used by some of our customers but regrettably this functionality will not be offered once we transition to XenServer. We believe the scaling options listed above plus load balancing will allow for dealing with the situations you have all mentioned.

@nickp: we are aware and understand the scope of the IP issue and are looking for creative solutions to it. This is one of the reasons we wanted to communicate all of this in advance of when it is actually occurring.

CommentAuthor Jered CommentTime May 4th 2011

@lethe: The DNS transition happening independent of your server migration means that you won’t have to change the DNS for your domains right away when you convert to Rackspace. The data for your DNS would still be on the Slicehost name servers, so you could postpone moving the DNS over to the Rackspace control panel until you’re finished testing the migration.

CommentAuthor nickp CommentTime May 4th 2011

@jimbattenberg: Thanks for the answers – I’m glad you’re aware of the importance of the IP issues.

From what we’ve heard about the transition process, we’ll be able to test out our new Rackspace Cloud servers prior to our Slicehost slices being shut off. Do you know how long we’ll be able to have both servers active? Allowing customers to transition to Rackspace proactively without impacting any production applications or websites seems like the only good solution if IP addresses cannot be transferred. That will allow us to transition the DNS for all of our customers without having to try to do so all at once. (Effectively, we’ll use our existing slices to proxy traffic to our new Rackspace Cloud servers, so that both the current and the new IP addresses will work at the same time.)

Finally, if it’s possible to do as I described and have both our new Rackspace Cloud servers and our existing Slicehost slices active at the same time, will Rackspace allow us to have the new servers at no cost during the transition period (say, 30 to 60 days)? I know you’re in business to make money and that you can’t give things away for free at will, but this seems an appropriate time and would greatly help ease the transition for many loyal Slicehost customers.

Also, I think you meant to say “May 2012” in your reply to @kohudson.

Thanks again for your time.

CommentAuthor RackspaceJeff CommentTime May 4th 2011

@wlashell - Based on your concerns I wanted discuss two distinct phases of the overall transition. One phase will not directly impact running services and only change the backend systems used to access your account. The other phase will function similar to a resize operation and will result in an interruption to service. Interpreting your comment, I believe you are asking about the second phase of the process. I have participated in a lot of migrations and definitely understand the various use cases for several smaller moves versus one single event. The way we have envisioned the process is that we will provide you a list of your current slices and the ability to select as many or as few slices as you want to move at that point in time (along with a “select all” if that is your preference). This functionality will be made available within SliceManager and will also keep track of the state of each slice (needs to migrate, in progress, or completed migration). I hope this helps you plan for the upcoming process and provides benefit to you and your business in the future.

Thanks for your question,


CommentAuthor Jered CommentTime May 5th 2011

On the question of historical bandwidth, I’ll find out what possibilities exist (how much the billing system keeps and for how long, how accessible it is, etc.), and I or someone else will let you know when we know more. I didn’t want the question to sit neglected, but I don’t really know our billing well enough to give a definitive answer.

Thankful People: MildredRod

CommentAuthor jimbattenberg CommentTime May 5th 2011

@nickp - really good idea. I don’t have the authority to make that decision, but I’ll take it to those that do. Probably not a quick answer here as I would image a few billing hurdles with implementing something like this (aside from the business decision)…but i like your proposal. As the answer might not be quick (or germane to this thread by the time i get it), would you mind shooting me an email? firstdotlast@rackspace? thanks.

CommentAuthor kohudson CommentTime May 5th 2011

@jimbattenberg, Thank you for responding to my question. However, I wasn’t really asking if we had to do a migration by May 2012 I was asking if we have to do a migration before then. I probably should have been more clear in my question. Basically, I’m asking if we can wait until the last minute or will there be some sort of schedule where certain migrations must be performed in August, others in September, etc. Thanks.

CommentAuthor RackspaceJeff CommentTime May 5th 2011

@kohudson I understand your question better now. The way this will work is that we will have migration windows for customers based on their location within the data centers. Depending on where your slice resides you will receive notification and be provided functionality within SliceManager to migrate your slice(s). We will seek to provide customers as much advance notice as possible but have not locked down a specific schedule I would be able to reference for your account at this time. We do not have plans to open any of the migration windows until Q3 at the earliest. I hope this better answers your question.

CommentAuthor mattbeck CommentTime May 5th 2011

Yesterday, at the request of whoever mans the rackspace twitter account I sent questions via email, but got no response, so I’m asking them here again.

1) Can we get a more solid confirmation that the non-STL data center customers will be able to keep our IPs? It sounds like a yes?

2) Will our 32bit slices migrate over or will we be forced to switch to 64bit distros?


CommentAuthor cameroncox CommentTime May 5th 2011

Will having an existing rackspace cloud account affect the transition from Slicehost? Or will that be accounted for?

Thankful People: deurbroucq

CommentAuthor RackspaceJeff CommentTime May 5th 2011

@mattbeck sorry for the delay in responding to your email but I can assure you we are going through the emails generated by this news and are responding to each in turn (I mention this because I am one of the people responding). The delay was caused by us wanting to finish the FAQ first so that we could stay consistent in our answers and not create more confusion. Here are the answers to your questions:

1) non-STL data center customers WILL be able to keep their IPs - confirmed yes

2) Your existing 32bit slices WILL migrate over. The issue is that right now Rackspace Cloud Servers do not offer 32bit images as part of their base images. This means new customers cannot select a 32bit image nor can existing customers spin up a 32bit server from a base (Non customer) image. In your case (I assume you already have running 32bit images) you will be able to spin up new 32bit servers by taking a snapshot of your existing slice and using it to build off of. Additionally, we are investigating adding 32bit options for the most popular distributions within Cloud Servers.

CommentAuthor mattbeck CommentTime May 5th 2011

@RackspaceJeff, perfect thanks.

I’m not worried too much about new slices. I have a mix of 32 and 64 bit slices, so i’m mostly concerned with what I have currently.

CommentAuthor kohudson CommentTime May 5th 2011

@RackspaceJeff, Thank you for your followup response regarding timing. However, in my opinion this is not an acceptable plan. Saying “Depending on where your slice resides you will receive notification and be provided functionality within SliceManager to migrate your slice(s).” doesn’t give me much to work with. How much notice will we receive? One week? One month? Can I plan a vacation for Q3/Q4? Go to a conference? Take on an additional project? Who knows? You’re telling me that you don’t know so there’s no way I could know.

In addition, for those of us with more than one slice who decides what order the slices are migrated? If it’s just based on “where your slice resides” then you may specify a schedule that involves migrating my production server prior to my staging server which is just the opposite of what I would choose. This is just unacceptable. You really must give all of us some kind of control over the scheduling of our migrations. Otherwise, I’m in a position where I have to go to another company just so I can exert some sort of control over my migration plan and scheduling.

CommentAuthor Jered CommentTime May 5th 2011 edited

POST EDITED: Oops, I didn’t have it all quite right, so I’m taking out what I’d posted. Jeff will explain more as he’s more acquainted with the process planned.

Short version: There’s a difference between the conversion to Rackspace (switching the billing over, moving between control panels) and the migration that will have to happen from some hosts (such as the STL datacenters) in order to move to machines running XenServer.

So the overall big window is for the conversion - that can happen any time once that process is in place.

The smaller windows will be for the hosts that have to be migrated as part of the switchover to XenServer. Unfortunately those will have to be scheduled within specific time periods. Like I said, more details coming.

I will add that manual migrations should still be possible if you want to migrate early to have more control over the timing. This article series describes migrating a server via rsync between services, so if you want to guarantee the data on a staging server gets transferred well in advance to give you plenty of time to test, that could be one approach to try to reduce uncertainty. It’s less painful than it sounds, and our support staff will certainly assist if you run into any snags when copying the data over.

CommentAuthor RackspaceJeff CommentTime May 5th 2011

@kohudson, As Jered mentioned we will have smaller windows for the switch to XenServer because we feel it is important to break up this conversion up into many smaller, manageable pieces rather than a single event. The method we chose to break up the process is mostly by how slices are allocated within the data center. Where customer slices would spill over our chosen breaks we will seek to expand the selection to give customers the ability to manage to their particular needs around maintaining an appropriate software development life cycle, keeping failover services alive, etc.

I want to make sure to note there are two distinct phases of this process. Phase one is a hypervisor maintenance to move over to XenServer (this is the process that will function very similar to a resize operation) and phase two is the actual conversion to Rackspace Cloud (this will not impact running services but will change how services are accessed). None of the phase one customer migration windows will start until mid July at the earliest, we will provide customers at least a month notice of when their migration window will open, and the window will stay open for at least 3 weeks. During your migration window we will provide you a list of your current slices and the ability to select as many or as few slices as you want to move at that point in time (along with a “select all” if that is your preference). This functionality will be made available within SliceManager and will also keep track of the state of each slice (needs to migrate, in progress, or completed migration).

CommentAuthor kohudson CommentTime May 5th 2011

OK. Thanks for the responses. It looks to me like I have 2 choices. First, wait until you tell me that I have to move and then I have 3 weeks to do it. Of course, I have no say and no control over when this happens. It will happen when it’s convenient for you. Second, I can do the migration manually with a schedule that meets my needs but with more down time and disruption to my users because it may not be simple or straightforward. Of course, if I choose option 2 then I could just go somewhere else. Pretty good summary of the situation? Bottom line: I’m not happy and I’m seriously disappointed in you all.

CommentAuthor aramisbear CommentTime May 5th 2011

@jimbattenberg regarding the creative solution to the IP address issue. Would it be possible for the “one button convert” to update the DNS records during the migration process? If that is too big of a risk could the DNS interface of the new control panel that you’re putting in place display a “X.X.X.X IP address was migrated to X.X.X.X address. Would you like to update the corresponding DNS records?”

Additionally, if this mapping information is tracked somewhere you could provide a script to handle updating /etc/hosts on each slice based on the mapping data so that servers within the walls of the data center could utilize the new mappings without waiting for DNS cache expiration. Having something that tied into an IP mapping API would dramatically speed up the lookup process though.

Additionally, if the new control panel could provide some alerts/warnings for IP addresses that used to exist for Slicehost customers which have suddenly gone away, that would probably go along way toward ensuring we don’t leave anything out.

Those were my first thoughts though. I’m sure ya’ll will come up with something solid.

CommentAuthor Jered CommentTime May 5th 2011

kohudson: To add to your assessment, the manual migration approach would probably involve less downtime than you’d think. Most of the rsync can occur with the server still running. Testing can likely occur after a basic sync, so you could experiment with the process without any disruptions for customers. If you’re hoping to be flexible with the schedule and aren’t sure we’ll be able to accommodate you properly with the automated process, then it may be worth looking into.

I’m not trying to discourage you from pushing for an automated solution more to your liking, mind you. I’m just doing my support thing.

CommentAuthor Jered CommentTime May 5th 2011

On the subject of historical bandwidth, I’m told we do not have prior bandwidth usage data stored in our billing system.

For now it appears the best bet for comparison purposes would be to set up something like munin (or another program that monitors and aggregates bandwidth data). It’s not as nice as historical billing data, obviously, but hopefully monitoring for a month or two will help give an idea of what you’d use before having to make a migration decision.

I’ll work on getting a short article up next week on setting up munin with bandwidth reporting, just to try to help out a little on that score.

CommentAuthor ronneseth CommentTime May 5th 2011

On the nameserver issue – nsX.slicehost.net.

Why can you not maintain nsX.slicehost.net (and point this at a rackspace nameserver). My customer are nontechnical, and getting them to change the nameserver settings on their domain is a major hassle.



CommentAuthor colinhines CommentTime May 5th 2011

I’ve spent years building my online reputation as a quality mail provider that is listed in many international databases keyed off of my originating IP address. Any IP change will seriously affect my business and my reputation and I need to make plans NOW to move to a different provider so I can start establishing a new reputation on a different set of IPs. Information such as “migrations will begin at the earliest in Q3”, does not provide me with enough information or time to plan this effectively.

I’m open to hearing about your creative solutions, but I’m concerned that there wasn’t enough consideration of the various applications that are tied to IP addresses.

I will also be contacting support directly to get a better understanding of where my slices sit so hopefully I can create a plan that is as harmless as possible to my reputation.


CommentAuthor jason CommentTime May 6th 2011 edited


While I certainly understand exactly where you are coming from, I do think that regardless of your hosting arrangement any IPv4 addresses you have built reputation on are going to be essentially worthless over the course of the next year as the entire world makes the move to IPv6.

You can see what datacenters your slices are in the slicemanager, just open up the specific slice view, it’s the like labeled ‘Datacenter’.

If I understand the plans correctly, stl-a and stl-b are eventually going to be phased out which means IPs are facing potential renumbering. All others are within ‘official’ rackspace DCs and should be able to retain their IPv4 IPs indefinitely.

From memory I can tell you that only a /22 (4 /24 or class C’s) of address space is actually not currently registered with slicehost or rackspace and all of it is contained in STL-A. The rest is at least eventually relocatable by rackspace, however due to the complications of route advertisement, I can definitely believe that the supported migration path will be to renumber even when migrating from STL-B.

And as a disclaimer - I’m not a rackspace employee and cannot speak authoritatively on this, just offering my own color.

CommentAuthor mark k. CommentTime May 6th 2011

OK, the suspense is killing me… Since I have decided that at least for now I’m going to migrate to RS cloud, I want to get over with it as soon as possible, especially since I don’t want to make any infrastructure related changes in my software when they might not be needed in the RS could.

So is there a way to sign up to be a beta tester/early adopter, to finish the process as early as possible?

CommentAuthor mwilliams CommentTime May 6th 2011

@jason: slightly off topic but why will reputation built on IPv4 addresses become worthless after the move to v6? Certainly it’s a larger address space but v4 addresses will persist and still be accessible by more devices and networks. I think I missed your point.

CommentAuthor johnatsatlantic CommentTime May 6th 2011

Since my account details are inside Slicehost I would hope that I can get a message detailing 1) where my slices are located, 2) which CloudServers match my slices on cpu,ram and disk, 3) and how my historical bandwidth would be priced.

The trial CloudServers will be useful, but since I have to start working on a migration on my schedule rather than yours, if I start using CloudServers now will there be any way for me to get a discount ?

Also, since I’m a current Slicehost customer (since late 2006) can you please dispense with the callback from sales to activate the server.

CommentAuthor Jered CommentTime May 6th 2011

johnsatlantic: Sending an email to support@slicehost.com or opening a ticket through the SliceManager would be the easiest way to get a response with some of that information, since that will make it easier to identify your account.

You can check the datacenter for a slice by looking at its details - the datacenter is at the bottom of the details list. “STL-A” and “STL-B” would be the only ones that are not already Rackspace datacenters.

The Cloud Servers pricing page lists the prices and packages available. They don’t have intermediate package sizes (384, 768, etc.), but the rest of the sizes should be roughly the same. Just bear in mind that bandwidth is charged separately from the package of memory and disk space.

Unfortunately our billing system does not store historical bandwidth use, so we can’t provide a comparison on that score. For now the best I can suggest would be to set up monitoring on your slices so you can aggregate your present bandwidth use and try to project from there.

CommentAuthor jason CommentTime May 6th 2011

@mwilliams - After a critical mass is reached, the only way anyone will see your IPv4 address is via some IPv6<->IPv4 proxy.

You cannot directly reach an IPv4 network using IPv6, you must cross some NAT device. The best transition path for most is to add IPv6 and run dual stack so that the same resources have both IPv6 and IPv4 addresses and the over time IPv4 usage wanes. There are other more complicated transition paths that involve NAT at the provider level, but the bottom line is that any new devices on the web after a certain point (likely a date in 2011, definitely by end of 2012) will have only IPv6 addresses so my point is that it is going to make sense of you to start ‘reputation building’ on an IPv6 block anyway.

CommentAuthor mwilliams CommentTime May 6th 2011

@jason: Thanks, interesting. I was assuming the current prominence of v4 addresses and the widespread lack of preparation for the transition would mean they remain in active use, combined with v6 addresses as you note. I believe my domestic ISP is planning to run 6-to–4 tunnelling for the immediate future for instance. It’s surprising to see how many VPS providers aren’t yet supporting v6 too. I guess v6 will become the preferred standard at some point though, so point taken.

CommentAuthor wphelps CommentTime May 7th 2011

A couple of suggestions for Rackspace.

1a)Create some plans that bundle Bandwidth AND Backups – some prefer a single number.

1b)Place no limit on backup file size – I could not find a file system with a 80GB limit, just cluster imposed limits; so create an over 80GB backup pool using larger clusters. Then all slices can be backed up.

2)For customers with slices in STL we don’t have a year *:-(; we only have a couple of months – “We expect to start the migration out of the STL DCs in Q3 2011.”

If the addresses are not kept then the migration will not be as easy as 1-click; many applications would need to have their configurations changed; even a simple application like Apache would require changing ‘listen’ statements and digital certificates. Nameservers, firewall rules both on-slice and elsewhere, antispam rules, monitoring, and remote access software would also need to change. Much of this may be within multiple organizations and require several people to spend hours of their time per slice. If you own the ASN’s(I know you have ours - 12200), and are not otherwise using the STL DC’s, please keep the IP Addresses!

Do a Live SH to SH DC migration for STL-A&B to newDC-A&B before any SH to CS migration – e.g. move the AS numbers to the routers at the new DC’s and tunnel back to old DC’s using something like VPLS so that the location of each IP can be controlled internally; migrate in batches(let the customers pick the time slot); continue running SH in the new DC’s; then in the future migrate between SH and CS.

Thankful People: DynamicBits, nickp

CommentAuthor johnpenn CommentTime May 7th 2011

First, I’d like to thank Mark for his thoughtful reply, it goes a long way to clearing up the gray areas and assuring me of the details of what’s to come. I’m generally optimistic for the future of this move, even though I do think that rackspace is aiming curiously low with their VPS specs, particularly when you consider competing VPS competitors. But I digress.

I would like to weigh in on bandwidth. I don’t know exactly what my bandwidth has been historically, but it’s certainly been under 60GB. I recognize that, and I recognize that I stand to save a few bucks per month with the move. However, my current plan includes 150GB of bandwidth for the same price. So, on paper, the new rackspace plan does threaten to take away 90GB of included bandwidth per month away from my plan.

The argument that most of us will save money makes a good case to be sure, but it also sounds a little flippant like, “look, it practically doesn’t matter for most of you.” If it practically doesn’t matter for most of us, it practically shouldn’t matter to rackspace either. Honestly. But the whole issue gets very interesting when you look at it from a revenue perspective. It’s like watching rackspace throw both money and good will away.

Consider AT&T. AT&T did a similar thing with iPhone customers and their unlimited* data plans. They capped bandwidth on new plans to 2GB or 200MB per month. The new plans were cheaper for most people – most customers able to cut their data bills in half – so there’s a strong fiscal incentive to migrate. AT&T also provided 6 months of bandwidth history so its customers could choose the plan that best fits them. Most importantly, AT&T kept the unlimited plan for existing customers. Many customers immediately switched to save a few bucks anyway. AT&T did this in a customer-friendly and it helped to keep people enlisted and to demonstrate the value of their customers.

Let me wrap this up. Offering a grandfather bandwidth package to slicehost customers is a potential profit center for rackspace: If a typical slicehost customer pays $20/month for a 256 slice and uses 11GB of bandwidth (10 out, 1 in), they’d pay less than $13 for rackspace hosting. If that customer wants to pay $20 to get additional bandwidth that they don’t use, then rackspace stands to generate 65% additional revenue from each of those customers while at the same time offering a tremendous amount of good will. It looks like a win-win to me, for what it’s worth.

Thankful People: mwilliams

CommentAuthor mwilliams CommentTime May 7th 2011

@johnpenn: I think you’ve nicely resolved some concerns in a pretty reasonable plan. I know there needs to be a sufficiently strong business case for any proposal but if the priorities for the change are more technological than financial, I’d hope fixed bandwidth options like yours might be viable. If RS need further convincing to permit the present plan pricing to continue, overage costs could even be slightly higher than the flat rates stipulated for straightforward cloud plans. The Q&A states “For higher bandwidth legacy Slicehost customers, we are investigating a bundled bandwidth option for Cloud Servers” but it’d be nice to see the option available to all customers.

CommentAuthor edgar CommentTime May 7th 2011

The only reason I don’t like “cloud hosting” is the utility based billing… Seriously, it will be cheaper than SH but who in the world would use a server without bandwidth?

Secondly, its quite assuring when you sign up for vps server somewhere that you have bandwidth to grow along with your site without forking up a bundle to run it.

VPS was meant to be a cheaper solution than a dedicated server. Looking at the bandwidth charges it would be more interesting to pay for a dedicated server or find a better vps host. You may reply and say a dedicated server doesn’t have room to grow…

IMO, cloud is just marketing ploy to make users feel like they are paying less but in the long run they will be paying more for bandwidth!!!

No bashing to your service, i just dislike utility based billing. Your goal on the internet is to attract more visitors not to be stagnant.

Cloud hosting with bandwidth included i would like it more.

CommentAuthor ryan-allen CommentTime May 9th 2011 edited

If we were to migrate our existing sites to RackSpace Cloud our hosting costs would increase 200% due to the bundled bandwidth not being included.

Regardless, I can’t say I have a lot of confidence in this migration process given the way this was announced. It’s nice to have this follow up but to receive an email from someone saying we are being forced to migrate and no mention of timeline doesn’t inspire confidence.

Investigation of bundled bandwidth for existing Slicehost customers doesn’t sound very promising. We’re looking at moving what we have hosted on SH elsewhere at this stage.

CommentAuthor crmacd CommentTime May 9th 2011

I migrated OFF of Rackspace CloudServers and moved to Slicehost for two reasons:

1.) Security.

2.) Performance. I currently run more than one site and a small gaming server on a single slicehost without traffic, i/o, or user perceived performance issues. I could not do this on my equivalent 256 RS cloud server.

Being a prior Racker I will give them the benefit of doubt - for now.

I’m not looking forward to having to “migrate” back. I hope to receive nothing less than ‘Fanatical Support’ during the migration. I also expect the ‘full disclosure’ core value to be upheld during this migration.

CommentAuthor tsw CommentTime May 10th 2011

This is a real bummer. Slicehost made me a happy camper with its straightforward tools and simple pricing. I’ve ran a few tests with Rackspace Cloud and it appears to be a competent cloud VPS offering, but it certainly doesn’t capture the “Built for Developers” vibe.

Where is the DNS management? Reverse DNS? And the API?

This transition shouldn’t have even been initiated before RSC had that service spooled up and ready to go. This alone will make me have to look elsewhere because I’m not about to start paying utility pricing for every zone. Its bad enough a few measly GBs of transfer can’t be included.

And how about account switching?

I actually am a developer and have access to multiple customer accounts (customers I regretfully had recommended to Slicehost BTW). Am I back to having to login to their accounts separately?

I’m seriously disappointed to see SH go. It was a solid offering that gave me the no-frills, but essential functionality I needed. Now, not only do I need to undertake multiple migrations for servers that were running just fine, but I have to figure out how to solve for the missing holes in RSC’s offering, and try and not pay more for it as well. This is about how I’m feeling right now: http://www.youtube.com/watch?v=afbLb8A6oSE

Thankful People: myphsto

CommentAuthor kohudson CommentTime May 10th 2011

One of my favorite movies and one of my favorite movie scenes. And it pretty much sums up my feelings, too!

CommentAuthor coxis CommentTime May 10th 2011

Hmm, so looking at Rackspace there is no bandwidth included…

How many people would like to move to Rackspace without bandwidth included and pay about 200% of what we pay now ? Clean situation that all of us will search for VPS for the same price ?

Could someone explain it to me because i am pretty confused about this.


CommentAuthor ryan-allen CommentTime May 11th 2011

There’s a performance comparison of VPS offering, it’s a bit old, does anyone have a link to a more current comparison?


I’ve been doing cost and feature analysis of alternatives, and Linode works out to be roughly equivalent for both features and price in regards to Slicehost current but on-the-way-out offering. Their control panel has an awful lot of tech features and they pool bandwidth as well.

CommentAuthor Ghan_04 CommentTime May 11th 2011 edited

That’s a good comparison, but it’s also a bit old, being from 2009. There are some other players in the ring as well such as 6sync and Storm on Demand that are offering cool deals in the VPS market.

A couple reviews:



It often depends on what exactly you need when making a good choice for a provider that fits you, so I like to keep informed about as many options as possible. :)

CommentAuthor mnordhoff CommentTime May 11th 2011 edited

Posted By: tsw

Where is the DNS management? Reverse DNS? And the API?

If by “Reverse DNS” you just mean being able to set the PTR for your IP(s), go to the cloud server’s page and click on the DNS tab. Scroll down if you have a really tiny monitor. ;-P

Posted By: coxis

How many people would like to move to Rackspace without bandwidth included and pay about 200% of what we pay now ?

I don’t have a link, but it’s been stated somewhere around here that most Slicehost customers use a small proportion of their bandwidth and would pay less at Rackspace. Or at least speculated, and it sounds like good speculation to me.

Of course, what matters to you is how much you’ll pay, and you’re the only one who knows that. (Or maybe you don’t know it, given the lack of information stored by Slicehost’s manager. But you can certainly find out.)

CommentAuthor coxis CommentTime May 11th 2011

About that bandwidth, taking me as example i use all of 450GB bandwidth from my Slicehost plan included.

So i would like to transfer my SliceVPS to VPS that includes similar plan that i can use, for similar price.

If i migrate to Rackspace and use 450GB probably the cost are going very big, am i correct.

Also i am thinking that many users use bandwidth in ‘big number’, not only me.

CommentAuthor mnordhoff CommentTime May 11th 2011 edited

Posted By: coxis

If i migrate to Rackspace and use 450GB probably the cost are going very big, am i correct.

Well, get out your calculator and find out. My calculator says your transfer fees would range from $36–81/month, depending on how much of it is incoming and how much is outgoing.

Edit: Formatting. Grumble…

CommentAuthor edgar CommentTime May 12th 2011

Incoming data: will be less if you are not accepting file uploads.

Outgoing data: most used bandwidth typically (HTML content, downloads or videos high bandwidth)

CommentAuthor pdbishop CommentTime May 12th 2011 edited


CommentAuthor jtric CommentTime May 23rd 2011

So, pretty stark silence on this topic - I’m assuming most people have already made the move to Linode.

I’m sure we aren’t a massive client for Rackspace, but we do spend a couple grand a year on our slices. The communication thus far on something that is going to have a massive impact on previous slicehost customers has been extremely disappointing.

I’m giving Rackspace the benefit of the doubt here - there are some appealing things Cloud Servers for our company, but a.) I’m hesitant because this whole announcement was handled so poorly, which doesn’t give me great confidence Rackpace’s future product plans will be customer driven and b.) we need to hear some solid dates on what is happening when by end of this week. Otherwise, we will probably start the move to Lindode as well next week so we can manage the migration on our timeline rather than Rackspace’s.

CommentAuthor Jered CommentTime May 23rd 2011

They’re definitely aware that the Slicehost announcement could have gone better, and they’re trying to learn from the experience. That means they’re being more careful with the next set of communications about the platform migration and IPv6 so there may not be more news this week. They do want to put more information out soon, but I suspect “soon” is a time range anywhere between this week and early to mid June.

CommentAuthor jtric CommentTime May 23rd 2011


Appreciate the response. I’m afraid we just can’t afford wait around. There are too many unknowns in the plan for us.

Thanks for everything at Slicehost, it has been a truly great hosting company. We’re sad to leave it this way.

CommentAuthor coxis CommentTime May 23rd 2011

I also want to tnx Slicehost, it was more than 3 years with them. I migrate to 6sync (easy transfer with extra help from team).

Tnx Slicehost but that migration process is too scarry for me.

CommentAuthor Jered CommentTime May 23rd 2011

Best of luck to both of you. You have to go with what your business needs, no hard feelings. ;)

Apart from the lack of a timeline yet, the migration as I understand it won’t really be all that scary. It’s a common enough perception that I’ll try to sum up the process again here. The basic steps:

If you’re in an STL datacenter, you get the most annoying bit. They’re staggering the migrations and you’d be notified of your “window” ahead of time (I think they want a month’s warning and a month’s window, but I could be wrong there). Your IP address would change. Presumably you’d be migrated to a server that’s already moved to XenServer so you won’t have to deal with another migration - just the billing switchover to Rackspace, which is a separate process (at the end of this list).

If you’re in a Rackspace datacenter (anything not STL), the XenServer migration will happen eventually - also staggered, but probably more strictly scheduled as they upgrade each host. I’d expect the downtime to be brief (not as long as a full migration between datacenters). This is a migration that will happen to all Cloud Servers customers too - it’s part of our IPv6 deployment.

At some point in the next year all Slicehost customers would have to switch their billing over from Slicehost to Rackspace Cloud Servers. You’ll choose when that happens - there will be a button in the SliceManager to trigger the switch. From what I’m told that won’t involve any downtime since it’s purely a change in the billing system.

And that’s it. The scary bits would be the timing and the length of the downtime, which I can’t provide right now. But from what I know of the plan they’re hoping to work with customers on the timing, and the downtime should be as minimal as possible for the function performed (the STL migrations would be mostly determined by the length of the data transfer, for example).

CommentAuthor myphsto CommentTime May 24th 2011

I have to echo tsw’s comments, this is pretty big bummer, and here is why: Slicehost = SIMPLE.

Clean, easy to understand and use website, admin interface, mobile application for not only the slices but most of all DNS. Anyone using Slicehosts for many domains will be feeling the DNS pain when forced to switch over. I know Rackspace purchased Slicehost to learn from them– well I don’t see the Rackspace toolset, site and interfaces having much knowledge transfer from why Slicehost was such a hit.

A couple of questions before we take our business elsewhere (help me stay!):

Why isn’t the RS DNS management as easy as Slicehost, AND included (and by that I mean having both a easy to use admin interface + mobile application to manage it)? Why the complicated billing? I don’t see how most users of Slicehost can feel the billing model is compelling vs. what we have today. We care about performance AND bandwidth! Why doesn’t RS management tools use openId and/or other standards based login and security? Seems either I missed something, or we’re going backward in that department.

Thanks to everyone who put Slicehost on the map. It’s always been a treat to login and manage my slices without the busy marketing, terrible page clutter and layouts that we find on nearly all the other providers (I’m looking at you 1and1 and RS!).

CommentAuthor Jered CommentTime May 24th 2011

Picking through the items you mention…

The mobile application for Slicehost was actually written by someone not affiliated with Slicehost. The same author wrote a similar mobile app for Rackspace Cloud (and he’d been hired by Rackspace since then).

The DNS management and the control panel in general are items Rackspace has admitted aren’t what they could be (politespeak for “eyesores”). Right now the guys at Cloudkick are working on a revamp of the control panel. I don’t know when it will be ready, but they’re definitely working from the premise that the existing cloud control panel isn’t good enough.

There’s a private beta right now for a DNS API for Rackspace. That should let those features get worked into their mobile app, and I’m told features in the API reflect some of the changes that will be made to the control panel.

It’s a different billing approach, definitely. We’re going from the package deal that includes a chunk of bandwidth to utility building that charges for specifically what resources you actually use. Most customers should see a decrease in costs when paying for as-you-go bandwidth, though not all. The general costs for the server packages (memory, disk space) are comparable, so it’s the bandwidth question whether you would pay less in a utility system (pay for what you use) versus a package system (where you pay for a chunk of bandwidth, whether you use it or not).

OpenID has its fans and detractors. I’m not sure if OpenID inclusion is part of the plan for the new control panel - I’ll see if I can find out.

CommentAuthor chris.mx6 CommentTime May 25th 2011

Goodbye Slicehost. Exactly four years after firing up a slice in St Louis, my account is now closed, and the apps are running on Linode. It was good while it lasted.

CommentAuthor aramisbear CommentTime May 25th 2011

What will happen with the Slicehost forums and articles?

CommentAuthor Jered CommentTime May 25th 2011

Not sure about the forums yet. The articles will get ported over to Rackspace’s knowledge base, or merged into existing articles there.

CommentAuthor overscan CommentTime May 27th 2011

Well, that’s goodbye from me then. I can’t afford the bandwidth on Rackspace for my web forum.

Luckily after asking around, a good friend of mine has a very underutilised dedicated server I can use for free with RAID 1 750GB disks, 4GB RAM and 1TB/month bandwidth, so long as I keep it up to date with OS patching for him. Hard to compete with that pricing :)

CommentAuthor niallone CommentTime May 31st 2011 edited

It’s been about a month now since the announcement and I was wondering if you could give us any further indication of timelines, I thought I read somewhere that migrations could start happening 30 days after the announcement?

Edit) - Also, I have a current Rackspace account, will I be able to port my servers into my existing account? (I saw that question asked on the first page of this thread and didn’t see where it was answered)


CommentAuthor Jered CommentTime Jun 1st 2011

I’m told it will be possible to transfer your servers to an existing RS Cloud account.

As to the migrations themselves, it looks like there are still some details being hammered out behind the scenes. Until they are we can’t give a reliable timeline. I’m hoping there will be more information to give out in a couple of weeks.

CommentAuthor odelong CommentTime Jun 13th 2011

We have not been with SliceHost long and have not completely finalized everything we would use our slice for. We keep coming up with new ideas of what we could do, and are finding new systems we might consider moving over to our slice. We have been working from an Ubuntu slice but if we add some new features we would need to switch to a Windows option. With this in mind, what sort of procedure would we need to go through to get moved from Slicehost to the Rackspace cloud system and have the OS changed to Windows in the process. Do we need to just have our Rackspace account set up and start from scratch (there is practically nothing on the current slice so this is an option) or do we have to wait and get our system migrated then reset the account to Windows and start over. Either approach is fine since we would really need to start from scratch anyways.

Thank you for the information.

CommentAuthor Jered CommentTime Jun 13th 2011

It sounds like the easiest approach for you, odelong, would be to just create a Rackspace Cloud account when you’re ready and make the Windows instance from there. If you still have a Linux server you want to hang on to when we add the option to switch then you’ll be able to just move the server and your balance over to the existing Cloud account.

You can’t really turn a Linux server into a Windows server anyway - even if you waited, it would still be a matter of making a new Windows instance and then copying over anything you wanted from the Linux server through SCP or the like. The only extra step in doing it now instead of later is that you’ll be entering your billing and contact data fresh for the Rackspace Cloud account instead of having all that information migrated for you.

CommentAuthor mikemac11 CommentTime Jun 13th 2011 edited

Goodbye Slicehost. The years have been great. I personally thought Rackspace acquiring you guys from the beginning was a bad idea. Sure, it did gave you room to grow, but I also knew that you would have to report to a higher up business and meet their profit margins. It is pretty obvious that the service stopped innovating after the deal went through.

Slicehost has always provided me with great support, performance, and made me feel at home. In the beginning I was even able to talk directly with the founders and listen to the future plans for the company in their podcasts, but that has since stopped since most of moved on to other ventures. I believe Slicehost is a great company, but took the wrong path.

On the matter of having to move to Rackspace cloud? That sounds like a joke to me. I have tried it and hated it. The control panel felt bloated and slow. Many features I enjoyed were missing especially in the field of DNS. I can only add A, CNAME, and MX record? Additionally, nothing capped or guaranteed like bandwidth is also dissatisfying.

I will give Rackspace’s cloud a little bit more time to see if anything changes, but right now I do not see the appeal. I can see the appeal to move to linode as others have posted in the past. Think that might end up being the best solution.

CommentAuthor aschwabe CommentTime Jun 14th 2011

I also want to second the pain caused by the loss of the St. Louis IP address blocks. These have been engrained in my soul for many years now. I also will really miss the simply reliable IP transit which St. Louis seemed to have going for it. A combo of Cogent & Level3 which had very little in the way of hiccups for most of my stay (over looking last year). By contrast my server instances at SoftLayer seem to drop off the net for no reason what so ever every couple of days with their “enhanced” network containing many more moving parts. I will miss the green & flat smokeping lines of the St Louis facility and the simple design that I feel made it so predictable.

I’ve been looking around for other VPS providers with similar DNS functionality and hourly billing options but haven’t made any decisions as to where I’ll end up. Zerigo looks like a good alternative to Linode for Linux VPS. They seem to have an excellent DNS control panel supporting GeoIP load balancing. Has anyone tried their VPS server product? Traceroutes indicate they are based in a data center utilizing Level3 IP transit in the Denver area.

CommentAuthor jwilhelm CommentTime Jun 14th 2011

aschwabe, I haven’t used Zerigo, but I’m finding 6sync to be a great alternative so far. Zerigo was on my “short list” of providers, but something just didn’t quite feel right about them; nothing I can quantify, just a feeling.

Anyhow, like I said, 6sync is working out great so far for me! :)

CommentAuthor Baruch CommentTime Jun 23rd 2011 edited

I have to say that I’m not altogether pleased by this change. Slicehost was attractive to me because of its simplicity, and because of its fixed monthly price. I always knew how much I’d have to pay for my slices, which made budgeting simpler for me.

I’m going to go through with the change, because the Slicehost guys have always been straight with me, and they’ve always been very helpful when I’ve had questions or problems. They’ve earned my respect and trust. So, while I am doubtful about how this will all work out, I’m going to rely on past performance and hope for the best.

Good luck to everyone…


Now I’m a little confused. According to the FAQ, a 512 Meg Rackspace VPS would cost about $21.95 a month, plus whatever bandwidth is used. Depending on use, this could work out cheaper than a similarly-sized slice. That’s nice. I used the calculator to estimate the cost of 100 GB up- and download (100 GB each), which brought the cost up to $47.90. That’s a bit pricey.

I compared the prices on two other services, 6sync and Linode. The price for a 512 Meg server was around $20 for each, and that included either 200 GB or 400 GB of bandwidth.

That being the case, what advantage is there in maintaining a Rackspace account, which could cost more than twice what the other services would? What incentive would anyone have for remaining with Slicehost/Rackspace, given that we’re all going to have to migrate anyway? We’ll face a new hosting company, a migration to new servers, potential loss of our IP numbers, and potential increase of our costs. We lose the fixed price we had before, which for some of us is an important feature. I don’t see any compelling reason for remaining with Slicehost/Rackspace, given these facts.

So, in brief: What reasons can you offer to justify our remaining with your service? Give me something to work with, will you? I like you guys and want to stay put if I can, but… I’ve got to have some sort of justification to do so. Thanks.

CommentAuthor Ghan_04 CommentTime Jun 24th 2011

The strength that Rackspace brings to the table is a lot of flexibility. Rackspace offers many other services such as CloudFiles, CloudSites, and management for cloud servers. In my opinion, Rackspace is good at bringing a fully-featured suite of hosting tools to the table, but they lack a strong competitive price structure for those who simply need a plain box in order to get underway. Rackspace does use older hardware than anyone else right now - their CPUs are early generation AMD Opterons, but to be fair the CPU is not usually the bottleneck in this area of hosting. The way I see it, Rackspace is only worth it if you are planning on utilizing their add on services, or if you are building/tearing down large amounts of servers frequently. For the small developer who is familiar with Linux, Linode and 6sync will give you more for your money.

CommentAuthor niallone CommentTime Jul 4th 2011

OK, I feel as though I have given you guys enough time to keep us in the loop as to what’s happening, I’m sick of popping back here to see if maybe you updated us to what the heck is going on. Over 8 weeks ago you announced a whole range of radical changes that will effect my business in every way possible, since then all I have heard is a bunch of um’s and ah’s with nothing concrete.

I’m sorry, but I put food on my dinner table from your service, I simply cannot afford to not be kept in the loop, I don’t really have any other path but to take all of my servers to another host.

You have people’s livelihoods in your hands and the least you could do is let us know what’s going on - it seemingly obvious that you just don’t give a damn.

You could learn a thing or two from this forum: http://forums.whirlpool.net.au/archive/1724177 Same sort of deal - an acquisition and migration of a hosting company… BUT… The CEO and CTO have been on there everyday replying to everyone’s question personally until well over midnight updating their clients as to how they are going, the progress they are making and problems they are running into - fyi that’s where my business is going.

Cya Slicehost.

CommentAuthor Jered CommentTime Jul 5th 2011

I can say some parts of the migration have been delayed while they work out problems they found in the process during testing. I think the overall result will be an improvement over the initial announcement, but I can’t say for sure until more testing is complete. When they give the go ahead to release more information we’ll certainly be posting it here.

CommentAuthor kohudson CommentTime Jul 14th 2011

OK Jered, fair enough. In the meantime, how are businesses that use Slicehost supposed to PLAN? I’m assuming Rackspace does some sort of planning so they must have some idea what that word actually means. Maybe not. In any case, I’m disgusted.

CommentAuthor jtric CommentTime Jul 15th 2011

This is exactly why we left - the potential impact of the announcement on our business combined with the lack of details prevented us from feeling comfortable about adopting a “wait and see” attitude.

I would recommend planning to transition to another service (even it it’s Rackspace Cloud) so you can do the move on your timeline.

We moved all our servers to Linode and have been very happy thus far. We have about twice the server horsepower for the same price we were paying with Slicehost, excellent custom service so far, and while their dashboard is not as simple and elegant as Slicehost’s it provides a lot more functionality.

CommentAuthor Jered CommentTime Jul 15th 2011

They’re still hammering out details, testing processes, and planning stuff. I’m afraid that’s as specific as I can get for now. I expect something soon, but “soon” is admittedly very non-specific.

We hope to make the transition an easy one, and I know the higher-ups are looking at ways to answer many of the concerns that have been brought up about the move. Addressing some of those concerns is why there’s been a delay in new information - they don’t want to promise anything unless they know they can commit to it. Until then the Slicehost servers aren’t going away, and nor are the staff who support them.

CommentAuthor seamanjeff CommentTime Jul 26th 2011

Really need some info soon. I cannot defend “limbo” to my management.

—– CommentAuthor Jered CommentTime Jul 28th 2011

Here is the latest information on the plans for Slicehost, as an update to Mark’s post.

Many Slicehost customers spoke up with concerns and ideas. Rackspace has been listening. As with all changes there are inevitable challenges, but we’ve been working very hard to make the transition as seamless (and acceptable) as possible.

Here’s what has changed, in no small part based on your feedback:

  • You will have the ability to downsize slices after the transition to Rackspace Cloud Servers.
  • If you’re in the STL-B datacenter you will be able to keep your public IP address.
  • We are working hard to make it easier for you to understand how this will affect your bill. In many cases customers will end up paying less.
  • Under the Rackspace Cloud program you will not have to pay for incoming bandwidth.
  • We are looking to make other changes based on the feedback we have received so far – stay tuned.

It is difficult to maintain and continue investing in two code bases that serve the same underlying customer need. Slicehost was, in fact, the foundation for the Rackspace Cloud Servers product. It is the same code base. That one is called “cloud” and has a different billing model from “slices” can be confusing, but under the covers it’s mostly the same platform.

Rackspace thought hard about the change and the impact to our customers and we believe the benefits outweigh the migration impact. Those benefits include IPv6 readiness, a better data center with newer servers, the ability to host in the UK, Microsoft Windows Server, Microsoft SQL Server, and more features to come. Take a look at this post to learn more about what is coming in the future.

The transition to Rackspace will take different paths depending on the location of a customer’s slices and the Linux distributions they use. Customers in our St. Louis datacenters will be migrated from those datacenters to Rackspace’s Chicago datacenter.

All Slicehost customers will go through a transition to the Rackspace system. Customers will move onto Rackspace’s utility billing system and move from the Slicemanager user interface to the Rackspace Cloud control panel. Once customers are on the Rackspace Cloud system they will have access to the full Rackspace product portfolio. We’re working on one-click-conversion tools to automate the process for you. You can find more details on the evolution of Slicehost in this post by Erik Carlin, the Chief Architect of our Cloud division.

We know how much Slicehost customers love the control panel and the forums. The current Rackspace Cloud control panel could stand to see some improvement. The good news is that we’re working on it. We have a team of Experience Design experts working on a new control panel that will be much better than what we have today. We hope you will like the end result as much as or better than the Slicehost control panel. For more details, read this post on our new control by Harry Max, our VP of Experience and Design.

Thanks again for your support during this transition. We really value your business. Our goal is that in a few months you end up in an even better place than you are today: your servers running on an open and powerful platform.

CommentAuthor mwilliams CommentTime Aug 1st 2011

A quick clarification: does the “incoming bandwidth” referred to at point 4 mean all incoming bandwidth or only that over Rackspace’s private network?


CommentAuthor Mr_T CommentTime Aug 1st 2011

mwilliams - Jered’s comment refers to all incoming network traffic, not just network over the internal network (a.k.a. ServiceNet).

CommentAuthor pombredanne CommentTime Aug 24th 2011

Posted By: Mr_T

mwilliams - Jered’s comment refers to all incoming network traffic, not just network over the internal network (a.k.a. ServiceNet).


Actually that was the only reason why I had started shopping elsewhere, but since this is settled, I can reconsider.

Just to make things are clear, does this applies to current slices and any additional Rackspace Cloud Servers I would provision?

CommentAuthor Jered CommentTime Aug 24th 2011

As I understand it, the elimination of charges for incoming bandwidth only applies to Cloud Servers (current and future instances) and Cloud Files.

CommentAuthor ajo CommentTime Aug 24th 2011

I’m one of the many who are no doubt considering a move away from Slicehost as a direct result of the changes you are making.

One of the things I don’t understand is that you are changing the pricing but despite having all the data to hand aren’t telling us how much we will have to pay going forward. It would be trivial for you to email each of your Slicehost customers and tell them how much they have paid for each of the last 3 months, for example, and how much they will pay for the same service under Rackspace.

Another thing I don’t get is why you don’t ‘do the right thing’ and simpy buy the IP blocks from their current ISP owner and transfer them to yourselves. Internal DNS conflicts are, in my opinion, your problem and should not be ours. After all it is you that wants the changes - I don’t think there are many Slicehost customers who are terribly keen on this extreme disruption …

Which leads me to my last point - we, your customers, are going to have to do a lot of work and spend many fraught and nervous hours migrating our various services so that you can cut your costs and thus improve your profits (which I applaud), surely you should be compensating us for the time we spend. The first three months of the Rackspace service being FOC would go a long way towards making up for the disruption and possibly even help you as a few folk would no doubt transition as soon as they could to take advantage.

*Comment on your post above - in the same paragraph it “is the same code base”, is “mostly the same platform” and is “two code bases”. No wonder we’re all so very very worried about this transition!

CommentAuthor Jered CommentTime Aug 24th 2011

Hm, that stuff about platforms should have been worded better, it’s true. I’ll leave it the way it is so others can make fun of me for it as well. Sorry about that. The basic intent was to say that, while some details differ on the backend, the basic operation of slices and cloud servers are largely indistinguishable for most users thanks to their common origin.

On billing, we don’t have historical breakdowns of charges stored. As a result we wouldn’t be able to provide accurate estimates of what equivalent usage would have been charged on Rackspace Cloud.

On the subject of the IP blocks, I can’t speak for the folks who actually make the decisions, but I wouldn’t think it’s easy to buy IPv4 blocks from anyone these days. The address space is being depleted too quickly, so companies are hoarding what they have. I’m not saying there’s no solution for that (again, I have no way of knowing what they have or haven’t tried), just pointing out that they can’t buy the blocks unless the owner is willing to sell.

And to the last, all I can say is that they’re still looking at options for the migration from the St. Louis datacenters and how it will affect customers. They’ll send details to affected customers when they’re ready to schedule migrations, explaining what will be involved and in what ways we can help to smooth the process.

CommentAuthor Mr_T CommentTime Aug 24th 2011

Hi there ajo,

It looks like your slices are in our DFW1 datacenter - if that’s really the case, then your slices will not experience any downtime, nor will their IP addresses change due to the transition from Slicehost to the Rackspace Cloud.

So really, there’s no work involved for you (if your slices are in DFW1, like I think they are).

There are two changes you’ll see, though: 1) the management interface will change from the SliceManager to the Rackspace Cloud control panel, and 2) the pricing will change, as you’ve noted.

On that note, I should say that we wold absolutely love to give you all of the historical bandwidth data for your slices, but the fact of the matter is that we don’t have it (at least, as far as I’m aware). I’m really sorry about that, and you’re welcome to shoot the messenger if you want, but I just wanted to get that out there.

Finally, for the “code base” bit, “the same code base” that Jered referred to is the back-end, while the “two code bases” he’s referring to are the front-ends. The “mostly the same platform” bit refers to the fact that the back-end is the same, while the front-end and billing systems are different.

CommentAuthor ajo CommentTime Aug 25th 2011

@jered - make fun? Do you really think any of this chaos is a laughing matter?

On one hand you tell us that most of us will pay less on Rackspace and on the other you tell us you don’t have the data to support the calculation. I guess you can make a few assumptions and figure out something semi-accurate but assumptions and semi-accurate don’t do much to allay folks concerns.

Oh and you absolutely do have a historical breakdown of charges stored - if nothing else the powers that be require you to keep such data. As Mr_T points out it’s the historical bandwidth consumption you might be missing but you’ve know about and been planning this move for how long? A year? If you’d started recording those stats a few months ago …

Re IPs - people will sell anything if the price is right! And if you offer your spare IPv4 blocks in exchange why wouldn’t they ‘sell’?

@Mr_T - while your news that I might not be affected at all is comforting the comfort is short-lived when I remember that it could easily be me affected next time …

Interesting how neither of you tackled the thorny question of reimbursement for those poor sods who’ll have to stay up late and sweat over their services in the months to come … Fingers crossed I’m not on that sorry list.

Having said all that I do realise that in some cases you are simply between a rock and a hard place but I guess that’s the price you pay for selling out to the evil IBM that is Rackspace. ;)

CommentAuthor Jered CommentTime Aug 25th 2011

Ajo, I’ve cracked wise at far less appropriate times than this. I do apologize if it seems I don’t take this seriously, but some people are just like that - I reflexively use humor as a response to tension. I’m not terribly good at being formal.

When I referred to a breakdown of charges, bandwidth use was primarily what I was thinking of. Slicehost packages include a certain amount of bandwidth, so anything under that amount wouldn’t have been charged on a bill. We can make guesses about simple price ranges like “more” and “less” by looking at current averages and extrapolating, but trying to be any more accurate than that just wouldn’t work.

To the rest, I can only tell you what I know, with some vagueness thrown in when topics touch on matters that haven’t been settled yet or where my information is incomplete. I’m afraid I’m not a decision-maker, just a tech who’s too much of a busybody to leave posts unanswered if I have anything I can contribute to a thread. So for example, “it’s being discussed” really is as specific as I (or Mr_T) can get on the question of how the St. Louis migrations are being handled. I clarify whenever I can, but if I don’t have a definitive, official answer, it would be irresponsible for me to offer conjecture.

That’s not to say that you shouldn’t complain or ask for more details - these posts are read by management, all of them, even the ones that sit unanswered longer than they should. So definitely keep the comments coming. Just consider this an apology from me in advance for the times when I can’t provide an ideal level of detail.

CommentAuthor Mr_T CommentTime Aug 25th 2011

ajo, like I said, if your slices are in DFW1 or ORD1, you will not have to sweat anything. If your slices are in STL-B, you won’t have to sweat anything, either, really - just some schedule-able downtime. On top of that, for those awesome long-term Slicehosters with slices in STL-A, we’ve assembled a crack team of transition experts tho make sure that there is no sweating. All of us at Slicehost and Rackspace are very aware of the potential sweating that could occur due to these transitions, and we aim to prevent it.

Just so you know, ajo, Rackspace is also migrating out of two datacenters in San Antonio as part of a separate effort. Additionally, we have already made at least one large datacenter migration in London. It’s this kind of shared knowledge that is being put to use in our STL-A and STL-B migrations to make sure there is no sweating.

Thankful People: mwilliams

CommentAuthor GerardoDada CommentTime Aug 27th 2011 edited


If you email me at product (at) slicehost.com with your slice number and/or primary email address I’ll be glad to confirm the datacenter where your slices are hosted and I might be able to provide bandwidth information and therefore an estimate of how much you will be paying under the Cloud Servers billing model. We estimate that over 80% of customers will receive lower monthly bills as a result of this change. Rackspace is not getting doing this to make more money.

When Slicehost started, as you can imagine is the case for a startup, they did not have the resources to have their own datacenters or to buy IP addresses in blocks. This is why STL-A is more affected. Rackspace was able to buy the IP addresses for STL-B. Once this whole move is compete you will be on a datacenter that is fully Rackspace owned and operated, where Rackspace owns the IP addresses. This should give you some confidence that you probably won’t need to move again.

I understand the change can be disrupting for some people’s businesses, for others, even in STL-A the change will be as simple as clicking on a button to start their migration and updating their DNS records to point to the new IP. The experience will be almost identical to a server resize: an image of your slice is created in the new datacenter, the data is synced, the slice is tested and the new image becomes your slice. For customers already in rackspace datacenters (ORD and DFW) there is no need to migrate anywhere.

I am not trying to over simplify, what I am suggesting is that we hope no one has to spend “ many fraught and nervous hours migrating our various services” because we are building automated migration tools. We understand that changing public IP address can be very problematic for some customers, this is why we have a migration team in place ready to help.

Ajo, please send me your info via email, I’ll send you the bandwidth, pricing and datacenter information.

CommentAuthor byclosure CommentTime Aug 29th 2011

@Mr_T - regarding the no sweating for the awesome long-term Slicehosters with slices in STL-A: what does “no sweating” really mean? Will the public IP addresses for the slices in STL-A remain the same or not?

CommentAuthor Mr_T CommentTime Aug 29th 2011

byclosure - unfortunately, slices in STL-A will not get to keep they’re IP addresses, but we want to do absolutely everything else we can do in order to make the migration as smooth as possible.

With permission, here’s an excerpt from a message GerardoDada sent to ajo that expands on my “no sweating” idea:

When Slicehost started, as you can imagine is the case for a startup, they did not have the resources to have their own datacenters or to buy IP addresses in blocks. This is why STL-A is more affected. Rackspace was able to buy the IP addresses for STL-B. Once this whole move is compete you will be on a datacenter that is fully Rackspace owned and operated, where Rackspace owns the IP addresses. This should give you some confidence that you probably won’t need to move again.

I understand the change can be disrupting for some people’s businesses, for others, even in STL-A the change will be as simple as clicking on a button to start their migration and updating their DNS records to point to the new IP. The experience will be almost identical to a server resize: an image of your slice is created in the new datacenter, the data is synced, the slice is tested and the new image becomes your slice. For customers already in rackspace datacenters (ORD and DFW) there is no need to migrate anywhere.

I am not trying to over simplify, what I am suggesting is that we hope no one has to spend “many fraught and nervous hours migrating our various services” because we are building automated migration tools. We understand that changing public IP address can be very problematic for some customers, this is why we have a migration team in place ready to help.

CommentAuthor Xof CommentTime Aug 30th 2011

I am still rather concerned that I am being forced from a fixed-price product to a variable-priced product with no real information as to whether or not this will be more or less expensive. (“Install munin”? Really?)

The pricing is not the technology. There is absolutely no reason that Rackspace could not, technically, continue to offer the fixed-price plans that Slicehost did. The primary attraction to me of Slicehost was that the pricing was highly stable. "Rackspace Cloud isn’t priced like that’ is evading the question.

CommentAuthor Jered CommentTime Aug 30th 2011

Speaking in general terms (since I’m not involved with money stuff here), I’d guess the trouble is that package pricing depends on the fact that some people use the service more and some use it less. The pricing can take that into account. If you mix that with the choice of a pay-as-you-go model you’ll end up with heavier users on the package pricing and the ones who use it less choosing the pay-as-you-go billing. The business wouldn’t be able to continue covering its costs unless the price of the packages went up anyway.

Again, I’m not a business guy nor a decision-maker, but that’s how I understand that general quandary. It’s why you don’t usually see the two pricing models mixed at a given company. An example is how ISP pricing works in the US and in Europe - in the US it’s a package model, where the casual Internet users basically pay for the extra bandwidth used by heavy downloaders. In Europe it’s all pay-as-you-go.

CommentAuthor rcorin CommentTime Aug 31st 2011

If you use a lot of the bandwidth, the variable priced model is much more expensive. 1 RS server with 256mb and 100gb outgoing bandwidth is 28.95$, whereas with SH is 20$ (150gb of total bw, i took 50gb for incoming traffic to be fair).

And… 1 linode server with 512mb , 200gb bw is 19.95$ !

In conclusion, if you consume, say, more than half bw then it’d stupid to stay. I’m willing to be proved wrong and convinced to stay since I like Slicehost and migrating to another host is a pain (with 20 slices), but given the current situation i’m going to leave.

CommentAuthor mikeysm CommentTime Aug 31st 2011 edited

If you use a lot of the bandwidth, the variable priced model is much more expensive. 1 RS server with 256mb and 100gb outgoing bandwidth is 28.95$, whereas with SH is 20$ (150gb of total bw, i took 50gb for incoming traffic to be fair).

Certainly agreed. With my current usage patterns and the usage patterns of my clients, my price would go from $268/mo (steady, month-to-month, easily billed to my clients) to a possible $680+/mo (could be a bit less, could be more). With our future expansion plans the price change would actually be $804 to $2,057.70. That doesn’t include the multitude of other Slicehost accounts that I manage for some of my clients.

Imagine making that kind of phone call to a client in these economic times, and imagine the repercussions of that.

Sadly, the price isn’t my only concern. But it’s at the forefront right now. I think the only part of this that I actually like is the transition to XenServer since we use that internally.

I’m pursuing the possibility of using Amazon EC2, which has a free lower tier for new customers. If configured properly, and with a little planning and auto-scaling, and with elasticity, scalability, free load balancing, super fast bandwidth speed, etc. my total cost per month would be far less than the new pricing tier here. And their prices keep dropping.

I apologize for the tone of this, but I am really unhappy right now – especially since the work involved with all of this is going to be a big drain on my already limited resources.

CommentAuthor jwilhelm CommentTime Sep 1st 2011

Posted By: rcorin

If you use a lot of the bandwidth, the variable priced model is much more expensive. 1 RS server with 256mb and 100gb outgoing bandwidth is 28.95$, whereas with SH is 20$ (150gb of total bw, i took 50gb for incoming traffic to be fair).

And… 1 linode server with 512mb , 200gb bw is 19.95$ !

In conclusion, if you consume, say, more than half bw then it’d stupid to stay. I’m willing to be proved wrong and convinced to stay since I like Slicehost and migrating to another host is a pain (with 20 slices), but given the current situation i’m going to leave.

rcorin, that’s actually a big reason I ended up leaving, myself. The stable pricing works, it has worked, it can be planned for. There’s no nasty surprises at the end of the month when you have a “good” month. I had to pull back and look at everything; I even built a spreadsheet of numerous competitors which is linked elsewhere in this forum. In the end, staying here just didn’t make sense, especially with the major breach of trust caused by this switch over and how it was presented.

Also, if the pain of migration is your biggest stumbling block, the guys over at 6sync helped me (for free) move all my stuff over to their servers. Just sayin’.

CommentAuthor Musfuut CommentTime Sep 2nd 2011

I used to be a Slicehost customer of 5 years and loved my service. I briefly considered going through with the migration to Rackspace as it would actually save me a bit of cash with my usage pattern. During those years I kept an eye on Linode VPS. I decided that they were a much better deal for me personally. I’ll end up paying the same as I was with Slicehost, for twice the ram and disk space. More bandwidth also but that wasn’t a selling point for me at the time. Their service appears to get better as time goes on as well.

I’ve been with them for three weeks now and am in absolute love over my service, the community, and the staff. It reminds me of the feelings I had when I first joined Slicehost.

I don’t like the way the Rackspace migration was or has been handled, I honestly feel like a pawn being shuffled from one square to the next.

So I’m a Linodian for life now. I want to thank Slicehost for being there in the beginning and giving me my first vps, despite everything I wish you the best.

Thankful People: Mayur23

CommentAuthor GerardoDada CommentTime Sep 2nd 2011 edited

this week we estimated the cost impact for every slicehost customer using all the data I had at hand. For every customer we estimating what their cost will be once converted to Cloud Server utility model using the average bandwidth consumed in April through June and then compared to the Slicehost cost without including any bandwidth overages.

If my calculations are correct, the average customer will se a price decrease of 33%, the median is a decrease of 42%. based on these calculations, fewer than 3% of all customers will see any price increase.

If anyone wants to know what is our estimated Cloud Server cost for their servers and bandwith utilization, please send me an email to product (at) slicehost.com with your slice number, or your customer number or your email address on record. We are evaluating making this data available on the slice manager.


CommentAuthor rcorin CommentTime Sep 5th 2011

I think it’s misleading to argue “most people will pay less”, when in fact your new pricing is actually offering the same product but charging more. The fact that people don’t use all the bw they pay for is a different issue than the fact that you’re increasing the price.

The only way it would be really fair is that if you charged each gb exactly what would correspond to the current SH pricing.

I’m now not also not staying myself but also recommending other people to leave as well: as most people would hope, if their bw increases, then they would end up paying more than currently. They lose either way.

CommentAuthor Jered CommentTime Sep 6th 2011

I would disagree about it being “misleading”. If you’re comparing what people pay in an average month then it’s a very straightforward comparison. Nothing misleading about it - under one system you pay X, under the other system, with the same usage, you pay Y.

Customers should take all the factors under consideration. The change removes the convenience of knowing exactly what you’ll pay each month, but for most users replaces that convenience with the benefit of paying for only what’s used. You can run into an unexpectedly high monthly bill if you have a usage spike one month, but if it was only a spike then the yearly average will probably still work out to less than what you were paying before. If the spike turns into a regular use pattern, though, you could potentially pay more on average than you had.

Either way, if you are worried about handling increased load in the future, you should take a look at your application architecture. Just speaking as a sysadmin in general, if you plan your app for scaling then it can be a lot easier to use whatever service/price structure suits your needs right now, then shift to another service if those needs change. You could start with one or two small servers, then if traffic picks up, start adding larger servers on another service with a pricing model that fits your new requirements.

So long as you have a single entry point in front (like varnish, apache, or nginx set up as a reverse proxy), then your backend servers can be anywhere - on the same server or on multiple services for extra redundancy or price advantages. A tool like blueprint, chef, or puppet can help bring extra servers up when they’re needed. So long as the app supports that kind of scaling you end up with a flexible environment that stays available to customers even if one of the backend servers goes down.

CommentAuthor rcorin CommentTime Sep 6th 2011

What’s misleading is that now you charge way more per Gb than before, as soon as you pass a low threshold.

There’s one other factor people should take into consideration: “With the new pricing, if your business grows in the future, hosting is going to be much more expensive too” .

This change has forced all your powerusers away, and is sending a strong message to the current users hoping to grow their business. I used to love this message:

“Sick of oversold, underperforming, ancient hosting companies. We took matters into our own hands. We built a hosting company for people who know their stuff. Give us a box, give us bandwidth, give us performance and we get to work.”

Let me ask you: do you really think you’re taking care of your customers that “know their stuff” with a forced migration & a huge cost increase?

CommentAuthor Ghan_04 CommentTime Sep 19th 2011

I found this post to be somewhat interesting:


Rackspace is massive and they are competing directly with Amazon. Unfortunately it seems to me that smaller developers get left out in the cold on this one and this explains why - they can afford to do it. Rackspace is so big that they don’t need to care about people with one or two slices. When it comes down to it, if you are a small developer and are being forced to move to RS Cloud, I see no reason whatsoever to stay here and not move somewhere like Linode or Storm on Demand. Rackspace has a lot of nice add-on features like the cloud storage and monitoring and management and so on, but the smaller people don’t need this. When you can get more resources with better hardware for the same price, it’s a no-brainer.

CommentAuthor Jered CommentTime Sep 20th 2011

Again, evaluate your needs and what they would cost, on Rackspace Cloud or elsewhere. Make your decision based on cost, services, and support. Take bandwidth and RAM into account, billing styles, all of that.

In my experience there’s no one-size-fits-all description that applies to all users, even in a category like “small developers”. A site that primarily serves as a web portal for users to download an application will have different server requirements, and billing advantages and disadvantages, from a site that experiences a lot of traffic and load fluctuations. Some might even find one service to be more advantageous for production and another service better for testing.

CommentAuthor johnatsatlantic CommentTime Sep 28th 2011

Is there any way to mark an STL slice as “do not migrate” ?

I’ve got rackspace cloud servers ready for my own transition as soon as I get the clients updated. Once I do my own transition I’ll just delete the corresponding slices.

CommentAuthor johnatsatlantic CommentTime Sep 28th 2011

Whats the status of the non-STL slices ?

Do their IP addresses remain intact.

CommentAuthor Jered CommentTime Sep 28th 2011

johnatsatlantic: When you’re contacted about migrating your slices you can let them know you won’t be using the automatic migration.

All non-STL slices will keep their IP addresses. For those slices the only change will be in how they’re billed once the conversion becomes available.

CommentAuthor GerardoDada CommentTime Sep 29th 2011

We made a number of changes over the last few months that result in only a very small group of customers losing their public IP addresses.


Servers in STL-A in the IP address range – will get a new public IP address and will need to update DNS records as part of the migration. All other slices will keep their public IP addresses.


All customers in STL datacenters will get a new private IP address

CommentAuthor sylmarsh CommentTime Nov 30th 2011

I’ve used the cloud in the past for storing and posting mp4 files. Is this still a viable use for us?

CommentAuthor matiu CommentTime Nov 30th 2011

I’ve used the cloud in the past for storing and posting mp4 files. Is this still a viable use for us?

Yes, the Cloud files with built in CDN magic is awesome.

I use cloudfuse to mount my cloud files account on my linux desktop at home. When I want to upload something, I just ‘cp’ it there. eg. cp awesomevid.mp4 ~/cloud/matiu/

By default ‘public’ cloud files containers provide a CDN (but not ‘private’ ones). Each container has it’s own base url, so I use DNS CNAME records so you’ll see if you: ‘dig cdn.supa.ws’ that cdn.supa.ws (my domain name) is a CNAME for ‘c631728.r28.cf2.rackcdn.com’.

I’m in Ausrtralia, so I get a 13 msec ping time to cdn.supa.ws (as the CDN pushes out a copy of the file to a local server (about an hour’s drive away) .. and I get a 250 msec ping time to most of the USA. and due to the effect of distance on download speed all downloads from the CDN are faster than downloads from America .. so clients of my sites see pics faster, no matter where they are.

in summary, either on my web server or on my local box:

  1. I mount the cdn: cloudfuse ~/cloud
  2. each subdirectory of ~/cloud/ is a container and has it’s own hostname, so I have ~/cloud/supa.ws/ point to cdn.supa.ws
  3. I either save images and vids (or other stuff) straight to ~/cloud/supa.ws/ .. or copy it there: eg: cp string.png ~/cloud/supa.ws/
  4. In about 1 second, it’s downloadable at http://cdn.supa.ws/string.png faster than if I downloaded it straight from the Slice

Also there’s an API for both cloud files

and for managing the content and caching on the CDN: http://docs.rackspace.com/files/api/v1/cf-devguide/content/API_Operations_for_CDN_Services-d1e2386.html

And implementations of the API for lots of different languages: https://github.com/rackspace

CommentAuthor louellman CommentTime Dec 9th 2011

I just received a quote from Rackspace to migrate our slices to the cloud. It is nearly twice what we are paying now!

Our current cost at Slicehost:

2 * 1GB Slices = $140
2 * 2GB Slices = $260
1 * Backups = $30
Total = $430

Cost for the same at Rackspace Cloud:

Cloud - Managed Services = $100
2 * 2GB = $390.40
2 * 1 GB = $302.80
Total = $793.20

This is $363 more than we currently pay! Seems excessive for a forced migration.

Am I missing something, or is this the official migration pricing?

CommentAuthor Jered CommentTime Dec 10th 2011 edited

Managed service is the one where Rackspace techs help maintain the server - that’s an extra $100 a month plus an additional fee per server. That’s definitely an extra compared to the Slicehost service, which is unmanaged (equivalent to the base Cloud Server product).

I’d suggest going to the Cloud Servers price calculator and plugging in details there (since the price would vary based on predicted bandwidth use):


CommentAuthor Tino Didriksen CommentTime Dec 10th 2011

Posted By: GerardoDada

…fewer than 3% of all customers will see any price increase.

Does that still hold? I just punched my numbers in the calculator and found that my price will go up from $130 to $142, before counting backups. That’s by using 300gb of the allotted 1200gb bandwidth.

So yeah, I’ll be looking to move to a cheaper place as soon as I get the time. I see other providers giving twice the hardware and bandwidth for half my current expenses…

© 2011-2013 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License

See license specifics and DISCLAIMER